Re: Introducing python3 into user system
On 17/10/2016 6:22 AM, Ruslan Makhmatkhanov wrote: > Hi, > > Python 2.7 will have no upstream support after 2020, and right now it > no more getting new features. So I'd want to start poisoning^W > introducing python3 into user system via ports tree and here is what > I suggest to start to do right now: > > - 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 > > We also need to explicitly mark python2-only ports to simplify > switching to python3 as default at some point of time. > > What you guys think about? If there is general consensus, we may > enforce this via Porters Handbook. > 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. I know quite a few other people have discussed at various times and in various levels of detail what & how FreeBSD might move to Python 3 by default, including some potential pitfalls that may need to be addressed. Vlad (cc'd) for example has been running an ongoing experimental Python 3 poudriere build to identify problematic ports for a while now. It would be good to bring all of that pre-existing discussion together. ./koobs ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov: > - 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 What do you mean by "force it"?. I agree python3 should be the default choice for all ports that can be installed with both python 2 and 3 if there is no python on the system. if python2 is already installed and python3 is not python2 should be used to reduce possible incompatibilities between programs. Regards Estartu signature.asc Description: OpenPGP digital signature
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/pyt...@freebsd.org.html Port| Current version | New version +-+ devel/py-setuptools | 28.1.0 | 28.6.0 +-+ devel/py-setuptools27 | 28.1.0 | 28.6.0 +-+ devel/py-setuptools33 | 28.1.0 | 28.6.0 +-+ devel/py-setuptools34 | 28.1.0 | 28.6.0 +-+ devel/py-setuptools35 | 28.1.0 | 28.6.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Introducing myself to the team
Hello list, just a quick Hello World and to introduce myself. I'm Vladimir Krstulja, some of you know me from Bugzilla which I help triage, and from IRC/Freenode as blackflow :) I'm a python programmer, I co-develop a rather large SaaS thing in my country (Croatia) which is built in Python and run on a heterogenous Debian + FreeBSD platform but we're moving it all to FreeBSD, and my interest is in improving the "Python experience" on FreeBSD by helping as much as I can. One of the projects I'm starting is a continuous Poudriere build of all things that USES= python, but for py35, in order to identify build failures for ports that declare all python versions but aren't really building with 3.x, or ports that limit themselves to 2.x but shouldn't really. I'm already dogfooding this, we run the SaaS with DEFAULT_VERSIONS= python=3 python3=3.5 and our (admittedly limited) use case supports it just fine. Python, uwsgi, nginx, PostgreSQL, Sphinx, etc... I'm hoping this will help speed up bringing Python 3.x default to FreeBSD. -- Vlad K. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
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 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. 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: 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. -- Vlad K. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing myself to the team
On Mon, Oct 17, 2016 at 11:58:42AM +0200, Vlad K. wrote: > and my interest is in improving the "Python experience" on FreeBSD by > helping as much as I can. Welcome. I'm glad to hear you are taking on this task. I am by no means an expert on poudriere but I do run some instances here, partly run by some custom scripts that build partial trees. (I developed them to speed up builds on tier-2 archs.) Let me know if you need any help in that area. mcl ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
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 ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
On Mon, Oct 17, 2016 at 01:35:45PM +0300, Ruslan Makhmatkhanov wrote: > 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). Although I'm the first to acknowledge that our wiki is a mess, this seems like an appropriate use of it. Please contact me off-line if you want help with that task. mcl ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
Gerhard Schmidt wrote on 10/17/2016 11:07: Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov: - 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 What do you mean by "force it"?. I mean set USES=python3.3+ for such ports. I agree python3 should be the default choice for all ports that can be installed with both python 2 and 3 if there is no python on the system. if python2 is already installed and python3 is not python2 should be used to reduce possible incompatibilities between programs. Regards Estartu Please see my comments to Vlad's response. This does not involve python "libraries" and standalone ports that depend on such "libraries". -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing myself to the team
On 17 October 2016 at 17:58, Vlad K. wrote: > > Hello list, > ... > I'm hoping this will help speed up bringing Python 3.x default to FreeBSD. > Welcome - and glad that someone is working on this task! Regards, Ben ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
On 2016-10-17 12:35, Ruslan Makhmatkhanov wrote: What I actually meant is to utilize USES=python:3.3+ for such ports, to make it pick up default python3 version. Yeah I "misunderstood you correctly", heh, sorry I wanted to say two different things at once The only problem with that (and btw, please let's use 3.4+ because 3.3 is badly supported even upstream) is ports that are dependencies to python:2 ports. So those would have to be identified, which is the idea behind my continuous poudriere run. IMHO variants are the only thing that would help us force all that can go py3 to go py3, and build py2 in support for rdeps that require 2. Because right now it's a bit of a mess when you have such conflicting requirements. -- Vlad K. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
Am 17.10.2016 um 12:39 schrieb Ruslan Makhmatkhanov: > Gerhard Schmidt wrote on 10/17/2016 11:07: >> Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov: >>> - 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 >> >> What do you mean by "force it"?. > > I mean set USES=python3.3+ for such ports. This will install python3.5 on this system regardless if there is a working python2.x installation, which is exactly what is wrong. I am a software developer who runs legacy systems on python2.7. Forcing ports that are able to run with python2.7 to install python3.5 will most probably break my systems. USES should always represent the minimum requirement not something so feel is something it should use. Please do not break systems without a really good reason. This we can discus in 4 years when support for python2 will end, but not until than. Not everyone has the freedom to run only shine new software on shine new systems. Regards Estartu signature.asc Description: OpenPGP digital signature
Re: Introducing python3 into user system
Gerhard Schmidt wrote on 10/17/2016 14:27: Am 17.10.2016 um 12:39 schrieb Ruslan Makhmatkhanov: Gerhard Schmidt wrote on 10/17/2016 11:07: Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov: - 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 What do you mean by "force it"?. I mean set USES=python3.3+ for such ports. This will install python3.5 on this system regardless if there is a working python2.x installation, which is exactly what is wrong. I am a software developer who runs legacy systems on python2.7. Forcing ports that are able to run with python2.7 to install python3.5 will most probably break my systems. USES should always represent the minimum requirement not something so feel is something it should use. I'm not sure how it will break anything if conditions, listed in my initial message are complied. Would you please elaborate on that and provide an example of such a breakage? python3.5 and python2.7 can co-exist. And I just want to remind that we are talking only about standalone applications now, with no external dependencies, and also about ports that use python only at build phase. Please do not break systems without a really good reason. This we can discus in 4 years when support for python2 will end, but not until than. Not everyone has the freedom to run only shine new software on shine new systems. Regards Estartu As far I understand, we should do some preliminary work to make it happen. We can't turn 26k of ports to using python3 in one day at 1st of January 2020. -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
On 2016-10-17 13:27, Gerhard Schmidt wrote: Please do not break systems without a really good reason. This we can discus in 4 years when support for python2 will end, but not until than. I agree with the bit of "let's not break systems", but not with the second part. Meanwhile, pkg variants will actually help going forward with ports that can run py35, enabling environments that want to be py35 exclusive while at the same time provide py27 environments where needed. So instead of "let's [do nothing and] discuss this in 4 years" I propose "let's see how to get variants going" :) https://reviews.freebsd.org/D5563 Because that 2.x EOL will come sooner than some would like and all those "let's discuss this later" systems will find themselves in hot water. I've been through that with PHP 5.3, needing to support clients that still, in 2016, required PHP <5.3 -- Vlad K. ___ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Re: Introducing python3 into user system
Am 17.10.2016 um 13:46 schrieb Ruslan Makhmatkhanov: > Gerhard Schmidt wrote on 10/17/2016 14:27: >> Am 17.10.2016 um 12:39 schrieb Ruslan Makhmatkhanov: >>> Gerhard Schmidt wrote on 10/17/2016 11:07: Am 16.10.2016 um 21:22 schrieb Ruslan Makhmatkhanov: > - 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 What do you mean by "force it"?. >>> >>> I mean set USES=python3.3+ for such ports. >> >> This will install python3.5 on this system regardless if there is a >> working python2.x installation, which is exactly what is wrong. I am a >> software developer who runs legacy systems on python2.7. Forcing ports >> that are able to run with python2.7 to install python3.5 will most >> probably break my systems. USES should always represent the minimum >> requirement not something so feel is something it should use. > > I'm not sure how it will break anything if conditions, listed in my > initial message are complied. Would you please elaborate on that and > provide an example of such a breakage? python3.5 and python2.7 can > co-exist. And I just want to remind that we are talking only about > standalone applications now, with no external dependencies, and also > about ports that use python only at build phase. Not everybody what's python3.x on his system. So way force 3.5 when it's not needed. Why should I install python 3.5 when i already have python2.7 installed and all the dependencies there. There is no sense in installing packages twice! As I said. Make python 3.5 the default if python 2.7 is not installed but don't force 3.x when there is no real reason. Just getting more installations isn't a valid reason to risk break it for someone. Regards Estartu signature.asc Description: OpenPGP digital signature
Re: Introducing python3 into user system
Am 17.10.2016 um 14:03 schrieb Vlad K.: > On 2016-10-17 13:27, Gerhard Schmidt wrote: >> >> Please do not break systems without a really good reason. This we can >> discus in 4 years when support for python2 will end, but not until than. > > I agree with the bit of "let's not break systems", but not with the > second part. > > Meanwhile, pkg variants will actually help going forward with ports that > can run py35, enabling environments that want to be py35 exclusive while > at the same time provide py27 environments where needed. > > So instead of "let's [do nothing and] discuss this in 4 years" I propose > "let's see how to get variants going" :) i didn't say do nothing. I just said don't force it. If there is no python (or python 3.x) on the system port's that can run on both should use python 3.x by default. If there is python2.7 on the system that should be used and not force the user to install python3.5 just to install a package that would run just fine on the already installed python2.7. Regards Estartu signature.asc Description: OpenPGP digital signature
