Introducing python3 into user system

[Ruslan Makhmatkhanov]

Vlad K. wrote on 10/17/2016 13:04:
> Hi all!
>
>
> On 2016-10-17 09:47, Kubilay Kocak wrote:
>> On 17/10/2016 6:22 AM, Ruslan Makhmatkhanov wrote:
>>
>>> - if port has a build dependency upon python and it can be built
>>> both with python2 and python3, force it to build with python3 - if
>>> some standalone application can be running both with python2 and
>>> python3 and it have equivalent python3 dependencies, force it to be
>>> run with python3
>
> This can be achieved now by setting DEFAULT_VERSIONS= python=3
> python3=3.5. See https://wiki.freebsd.org/DEFAULT_VERSIONS

You may now omit python3=3.5, because 3.5 is default since r423986. And 
what I actually suggested is not to change default version to python 3.x 
overall in ports at this moment. I suggested to do that just for some 
ports, that have python as build-only or run-only dependency, if the 
software in question is capable to run with python3. This is only needed 
to increase involvement of python3 in ports tree and user system, so we 
can catch up any FreeBSD-specific problems at early rate.

This one is a good example: net/openpgm. It does not install any python 
libraries and does not need python to run. Python is just used in build 
process so nothing prevent us to build with python3 by default.

>
> And if I misunderstood you correctly and you meant force it via port
> itself, I don't think we have a mechanism for that and even if we did,
> that'd be very bad.

What I actually meant is to utilize USES=python:3.3+ for such ports, to 
make it pick up default python3 version. And citing myself:

"""
- if some standalone application can be running both with python2 and 
python3 and it have equivalent python3 dependencies, force it to run 
with python3
"""

So if there are no equivalent py3 ports for dependencies, we do not 
change anything, for sure. Most of python libraries are not fall into 
this category also.

> One such problem I've noticed is with shared dependencies. If port X can
> work with 3, and port Y can only work with 2, and both have a common
> dependency Z which can run both 2 and 3, Z won't be built for both,
> it'll be built for DEFAULT_VERSION version, and if that's 3, it spells
> trouble for Y. It'll build fine, but Y will fail at runtime.
>
> Case in point was building py-sphinx and saltstack with Py3.5 set as
> default. They both have a dependency that broke sphinx, iirc.
>
> To fix this we desperately need variants. https://reviews.freebsd.org/D5563
>
>
>>> We also need to explicitly mark python2-only ports to simplify
>>> switching to python3 as default at some point of time.
>
> Definitely. I've started doing that, and caught some. weechat was one of
> them which has been fixed now. But, because of my build server
> reorganization I had to stop with that for some time and will pick it up
> again with a permanent, bi-weekly (twice a week) poudriere build of ALL
> ports that USE= python, with a public poudriere status page so we can
> track how it goes.
>
>
>
>>> What you guys think about? If there is general consensus, we may
>>> enforce this via Porters Handbook.
>
> I'm not sure the PHB is the right place. When I get the continuous
> poudriere build going, I'll post to the mailing lists announcing it,
> with an intention to pretty please let's switch to py3 as soon as
> possible. Also see next:

Ok, PHB was just an example. But it should be some "authoritative" place 
to encourage people to change their ports and to prevent adding of new 
ports without specific python version set (I still see many new ports 
added with just USES=python, while it may not build with python3 at all).

I also like koobs approach to formalize the roadmap, but right now I 
only can say that we can do the separation of python2-only ports till 
the end of the year. And maybe switch build-only ports to python3 by 
default. But I'm not yet sure what should be the next step.

>> I suggest we document something like a 'Road to Python 3 as Default'
>> page in the Python/ wiki outlining the goal (with timelines),
>> motivation, potential problems and possible alternative methods. Kind of
>> like a Python PEP.
>
> Definitely. I was thinking about that, inspired by Bernard's LibreSSL
> list of ports that fail, to have a list of ports that:
>
> a) Have USE= python but fail on 3
> b) Have USE= python:2 but are actually supported on 3
>
>
> But I need to get that poudriere running with a public status page for
> that.


-- 
Regards,
Ruslan

T.O.S. Of Reality