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 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
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: lang/python3* ports, __pycache__ included
On 2016-12-13 11:59, Kubilay Kocak wrote: Note that they will be re-created on import unless one overrides the default for the interpreter to produce these optimization files. Depends. Those modules are installed in a root owned directory, and the bytecode cache will get created only if you run (import is enough as you say) those modules as root, because the cache is written in the module package directory. So pre-packaging the bytecode is a form of optimization, as the bytecode will be there when you run it as an unprivileged user. -- 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: lang/python3* ports, __pycache__ included
On 2016-12-13 12:36, Kubilay Kocak wrote: My main point was that if disk utilisation is something one wants to minimise (at deployment), that one would need to be able to turn the optimization knob off each time (or system-wide) and that that would be a handy thing to know and do. Personally, I'd love if Python could specify a base dir for bytecode cache, but it seems that's not gonna happen: https://www.python.org/dev/peps/pep-0304/ Said another way, even if we (FreeBSD) de-packaged optimization files which we want to do, that that *by itself* that would only save package repository size and bandwidth, not deployment size. But in reality, what kind of gain/loss are we talking about here? I'm guessing it's pretty insignificant in this day and age, even for embedded? -- 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"
