Python default version

[Ryan Schmidt]

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.