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
