Python default version

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Python default version

Ryan Schmidt-24
The python portgroup defaults to version 2.7, and in ports that have python variants, I've used that version by default as well.

I was reminded by the members of the MacPorts meeting that it has been announced that python 2's end-of-life will be in 2020, which is coming up.

Should we change the default python version to 3.6 now, or soon?

Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Mark Moll


> On Mar 12, 2018, at 9:46 AM, Ryan Schmidt <[hidden email]> wrote:
>
> The python portgroup defaults to version 2.7, and in ports that have python variants, I've used that version by default as well.
>
> I was reminded by the members of the MacPorts meeting that it has been announced that python 2's end-of-life will be in 2020, which is coming up.
>
> Should we change the default python version to 3.6 now, or soon?
>

+1.

Many Linux flavors have also switched in their latest release to 3.6 (or are in this process of switching). I can’t think of any major python package that doesn’t work with python 3.6. I have been using “+python36” as a default variant on my machine without any issues.

Mark


signature.asc (849 bytes) Download Attachment
db
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

db
In reply to this post by Ryan Schmidt-24
On 12 Mar 2018, at 15:46, Ryan Schmidt <[hidden email]> wrote:
> Should we change the default python version to 3.6 now, or soon?

Soon. Btw, https://brew.sh/2018/01/19/homebrew-1.5.0/ (first bullet).
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Jackson Isaac-2
In reply to this post by Ryan Schmidt-24
On Mon, Mar 12, 2018 at 8:16 PM, Ryan Schmidt <[hidden email]> wrote:
> The python portgroup defaults to version 2.7, and in ports that have python variants, I've used that version by default as well.
>
> I was reminded by the members of the MacPorts meeting that it has been announced that python 2's end-of-life will be in 2020, which is coming up.
>
> Should we change the default python version to 3.6 now, or soon?
>

I agree to the decision to default to Python 3. I would say we should
set a milestone for the default version.

Probably in the next release cycle ?

I have been using Python3 for my work most of the time.
Haven't really touched Python2 much in a long time other than for some
particular use case.


--
Jackson Isaac
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Perry E. Metzger
In reply to this post by Ryan Schmidt-24
On Mon, 12 Mar 2018 09:46:36 -0500 Ryan Schmidt
<[hidden email]> wrote:
> The python portgroup defaults to version 2.7, and in ports that
> have python variants, I've used that version by default as well.
>
> I was reminded by the members of the MacPorts meeting that it has
> been announced that python 2's end-of-life will be in 2020, which
> is coming up.
>
> Should we change the default python version to 3.6 now, or soon?
>

I think we should, yes.

--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Mojca Miklavec-2
In reply to this post by Ryan Schmidt-24
On 12 March 2018 at 15:46, Ryan Schmidt wrote:
> The python portgroup defaults to version 2.7, and in ports that have python variants, I've used that version by default as well.
>
> I was reminded by the members of the MacPorts meeting that it has been announced that python 2's end-of-life will be in 2020, which is coming up.
>
> Should we change the default python version to 3.6 now, or soon?

What does that change actually mean? Which software could potentially
be affected?

I don't quite understand all the consequences since we are not
installing "python" by default and most of our ports specify python
version in one way or another and also make sure that the "correct"
version of python is being used.

(At the moment we don't even ship any Python 3-compatible solution for
wxWidgets, buildbot etc.)

It could be nice if someone finds a way to list all ports where
something could potentially change if default python version gets
changed.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Perry E. Metzger-2
On Mon, 19 Mar 2018 16:09:11 +0100 Mojca Miklavec
<[hidden email]> wrote:

> On 12 March 2018 at 15:46, Ryan Schmidt wrote:
> > The python portgroup defaults to version 2.7, and in ports that
> > have python variants, I've used that version by default as well.
> >
> > I was reminded by the members of the MacPorts meeting that it has
> > been announced that python 2's end-of-life will be in 2020, which
> > is coming up.
> >
> > Should we change the default python version to 3.6 now, or soon?  
>
> What does that change actually mean? Which software could
> potentially be affected?

I imagine this would mean at least that new and updated Portfiles
would specify 3.6 as their default version, and that we would update
old Portfiles that already specify that they can run on python 3.6 to
use that.

This would likely leave a large residue of Portfiles that should be
slowly examined for updates so that within a year or so, they're all
python 3 compatible.

> (At the moment we don't even ship any Python 3-compatible solution
> for wxWidgets, buildbot etc.)

Presumably we would want to fix that. It would not need to be a rush,
of course, since we still have something like two years before 2.7
becomes deprecated, but it would be reasonable to slowly and
deliberately get ourselves there rather than having to rush at the
last moment.

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Ryan Schmidt-24
In reply to this post by Mojca Miklavec-2

On Mar 19, 2018, at 10:09, Mojca Miklavec wrote:

> On 12 March 2018 at 15:46, Ryan Schmidt wrote:
>> The python portgroup defaults to version 2.7, and in ports that have python variants, I've used that version by default as well.
>>
>> I was reminded by the members of the MacPorts meeting that it has been announced that python 2's end-of-life will be in 2020, which is coming up.
>>
>> Should we change the default python version to 3.6 now, or soon?
>
> What does that change actually mean? Which software could potentially
> be affected?
>
> I don't quite understand all the consequences since we are not
> installing "python" by default and most of our ports specify python
> version in one way or another and also make sure that the "correct"
> version of python is being used.
>
> (At the moment we don't even ship any Python 3-compatible solution for
> wxWidgets, buildbot etc.)
>
> It could be nice if someone finds a way to list all ports where
> something could potentially change if default python version gets
> changed.

I should clarify that there's nothing special in my proposal about Python 3.6. I'm merely proposing that when we use Python, we should now prefer to use the latest stable version of 3.x, not the latest stable version of 2.x. If stable Python 3.7 is released tomorrow, then my proposal updates from 3.6 to 3.7.

The python-1.0 portgroup currently says:

proc python_get_default_version {} {
    global python.versions
    if {[info exists python.versions]} {
        if {[lsearch -exact ${python.versions} 27] != -1} {
            return 27
        } else {
            return [lindex ${python.versions} end]
        }
    } else {
        return 27
    }
}

In other words, 27 (2.7) is currently the default Python version. If a port doesn't specify its python.versions, 27 will be used. And if a port has multiple pyXY-* subports, and 27 is among them, then that will be one upon which the py-* stub port depends, otherwise the newest Python version listed will be used.


I'm proposing that the portgroup should require ports to specify python.versions. Don't offer a default. Identify and update all ports that use the python portgroup but that don't set python.versions. Set python.versions to 36 in those ports and increase their revisions. I'm also proposing that the default subport would change from the 27 subport if present to the latest 3x subport present.

Ports that don't use the python portgroup, but which use python, may have used python27 because that was the portgroup's default. Those ports should be identified and switched to python36, after verifying that that works. There may be many instances where it does not work, since python3 is different from python2. If a program doesn't work with python3, and the developers are still in existence, they could be contacted to work through those issues.

Other ports may offer pythonXY variants, and may have defaulted to python27 because that was the portgroup's default. They may not offer python3x variants, or they may only offer older python3x variants, perhaps because they have not been updated since python36 became stable. Since the python3x variants are not default, they may not be well tested, may no longer work, or may never have worked. Those ports should be identified, newer python variants should be added if they work, broken python variants should be removed, and the default should be changed to the latest python variant.


Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Ryan Schmidt-24

On Mar 19, 2018, at 10:52, Ryan Schmidt wrote:

> I'm proposing that the portgroup should require ports to specify python.versions. Don't offer a default. Identify and update all ports that use the python portgroup but that don't set python.versions. Set python.versions to 36 in those ports and increase their revisions. I'm also proposing that the default subport would change from the 27 subport if present to the latest 3x subport present.

The default subport is controlled by python.default_version, and we should require ports to specify that too.

Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Mojca Miklavec-2
In reply to this post by Ryan Schmidt-24
On 19 March 2018 at 16:52, Ryan Schmidt wrote:

>
> I should clarify that there's nothing special in my proposal about Python 3.6. I'm merely proposing that when we use Python, we should now prefer to use the latest stable version of 3.x, not the latest stable version of 2.x. If stable Python 3.7 is released tomorrow, then my proposal updates from 3.6 to 3.7.
>
> The python-1.0 portgroup currently says:
>
> proc python_get_default_version {} {
>     global python.versions
>     if {[info exists python.versions]} {
>         if {[lsearch -exact ${python.versions} 27] != -1} {
>             return 27
>         } else {
>             return [lindex ${python.versions} end]
>         }
>     } else {
>         return 27
>     }
> }
>
> In other words, 27 (2.7) is currently the default Python version. If a port doesn't specify its python.versions, 27 will be used. And if a port has multiple pyXY-* subports, and 27 is among them, then that will be one upon which the py-* stub port depends, otherwise the newest Python version listed will be used.
>
>
> I'm proposing that the portgroup should require ports to specify python.versions. Don't offer a default. Identify and update all ports that use the python portgroup but that don't set python.versions. Set python.versions to 36 in those ports and increase their revisions. I'm also proposing that the default subport would change from the 27 subport if present to the latest 3x subport present.
>
> Ports that don't use the python portgroup, but which use python, may have used python27 because that was the portgroup's default. Those ports should be identified and switched to python36, after verifying that that works. There may be many instances where it does not work, since python3 is different from python2. If a program doesn't work with python3, and the developers are still in existence, they could be contacted to work through those issues.
>
> Other ports may offer pythonXY variants, and may have defaulted to python27 because that was the portgroup's default. They may not offer python3x variants, or they may only offer older python3x variants, perhaps because they have not been updated since python36 became stable. Since the python3x variants are not default, they may not be well tested, may no longer work, or may never have worked. Those ports should be identified, newer python variants should be added if they work, broken python variants should be removed, and the default should be changed to the latest python variant.

OK, so basically you are proposing to modify our (non-written?) rules
about how to handle python ports, potentially open a ticket listing
some hundreds of ports to be handled and then slowly migrate on
port-by-port basis, which might just as well take longer than the
python 2.7 lifetime anyway?

Sure, I totally support that.
(In some of my ports I added python3x variants or subports for
testing, but they don't work correctly yet, so it's not just a matter
of mass-replacing the default version.)

What would help enormously and I also missed that since the time I
started touching any Python ports is the ability to use python (or
python-something) PortGroup which would not irreversibly change half
of the steps used to build a port, but merely allow to specify
something like

python.versions 27 36
python.default_version 36
python.create_variants
python.require_variants yes

with the sole effect of creating
    variant python27 conflicts python36 {}
    variant python36 conflicts python27 {}

and then allow using variables like
    depends_lib-append port:${python.port}
    configure.arg-append --with-python=${python.bin}

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Ryan Schmidt-24

On Mar 20, 2018, at 03:48, Mojca Miklavec wrote:

> On 19 March 2018 at 16:52, Ryan Schmidt wrote:
>>
>> I should clarify that there's nothing special in my proposal about Python 3.6. I'm merely proposing that when we use Python, we should now prefer to use the latest stable version of 3.x, not the latest stable version of 2.x. If stable Python 3.7 is released tomorrow, then my proposal updates from 3.6 to 3.7.
>>
>> The python-1.0 portgroup currently says:
>>
>> proc python_get_default_version {} {
>>    global python.versions
>>    if {[info exists python.versions]} {
>>        if {[lsearch -exact ${python.versions} 27] != -1} {
>>            return 27
>>        } else {
>>            return [lindex ${python.versions} end]
>>        }
>>    } else {
>>        return 27
>>    }
>> }
>>
>> In other words, 27 (2.7) is currently the default Python version. If a port doesn't specify its python.versions, 27 will be used. And if a port has multiple pyXY-* subports, and 27 is among them, then that will be one upon which the py-* stub port depends, otherwise the newest Python version listed will be used.
>>
>>
>> I'm proposing that the portgroup should require ports to specify python.versions. Don't offer a default. Identify and update all ports that use the python portgroup but that don't set python.versions. Set python.versions to 36 in those ports and increase their revisions. I'm also proposing that the default subport would change from the 27 subport if present to the latest 3x subport present.
>>
>> Ports that don't use the python portgroup, but which use python, may have used python27 because that was the portgroup's default. Those ports should be identified and switched to python36, after verifying that that works. There may be many instances where it does not work, since python3 is different from python2. If a program doesn't work with python3, and the developers are still in existence, they could be contacted to work through those issues.
>>
>> Other ports may offer pythonXY variants, and may have defaulted to python27 because that was the portgroup's default. They may not offer python3x variants, or they may only offer older python3x variants, perhaps because they have not been updated since python36 became stable. Since the python3x variants are not default, they may not be well tested, may no longer work, or may never have worked. Those ports should be identified, newer python variants should be added if they work, broken python variants should be removed, and the default should be changed to the latest python variant.
>
> OK, so basically you are proposing to modify our (non-written?) rules
> about how to handle python ports, potentially open a ticket listing
> some hundreds of ports to be handled and then slowly migrate on
> port-by-port basis, which might just as well take longer than the
> python 2.7 lifetime anyway?

Right, I'm proposing changing our unwritten policy regarding which Python we want to use by default. Our current policy isn't written in documentation but is implied by the behavior of the python-1.0 portgroup. So I propose changing the python-1.0 portgroup. Whereas we (or at least I) previously used python27 as default, unless a port required python3x, I propose that we now prefer to use the latest python3x, and only use python27 if a port doesn't support python3 (and ideally we work with the developers to add python3 compatibility).


> Sure, I totally support that.
> (In some of my ports I added python3x variants or subports for
> testing, but they don't work correctly yet, so it's not just a matter
> of mass-replacing the default version.)

Exactly, it's not a replace-all situation. Each port needs individual testing and possible patches. Which is why I would not want to create a single ticket to track them all; those tickets are really difficult to deal with. You want bite-sized tickets where you can make a small change and resolve the ticket.


> What would help enormously and I also missed that since the time I
> started touching any Python ports is the ability to use python (or
> python-something) PortGroup which would not irreversibly change half
> of the steps used to build a port, but merely allow to specify
> something like
>
> python.versions 27 36
> python.default_version 36
> python.create_variants
> python.require_variants yes
>
> with the sole effect of creating
>    variant python27 conflicts python36 {}
>    variant python36 conflicts python27 {}
>
> and then allow using variables like
>    depends_lib-append port:${python.port}
>    configure.arg-append --with-python=${python.bin}

It's not related to the python default version issue, but yes, that would be helpful. Currently the python-1.0 portgroup makes no attempt to help with the creation of variants, and I wouldn't expand its scope to include that. But there are several examples of automated variant creation in many portgroups and ports, for different variant groups (python, gcc, clang) and it might be worthwhile to see if we could create a new portgroup or MacPorts base procedure that would automate the creation of any group of variants.

Reply | Threaded
Open this post in threaded view
|

Re: Python default version

Perry E. Metzger
On Tue, 20 Mar 2018 13:43:59 -0500 Ryan Schmidt
<[hidden email]> wrote:
> Right, I'm proposing changing our unwritten policy regarding which
> Python we want to use by default. Our current policy isn't written
> in documentation but is implied by the behavior of the python-1.0
> portgroup. So I propose changing the python-1.0 portgroup. Whereas
> we (or at least I) previously used python27 as default, unless a
> port required python3x, I propose that we now prefer to use the
> latest python3x, and only use python27 if a port doesn't support
> python3 (and ideally we work with the developers to add python3
> compatibility).

This seems like a straightforward and sane policy.

Perry
--
Perry E. Metzger [hidden email]