Python default version

[Mojca Miklavec]

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