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.
