On 1 August 2017 at 03:47, Barry Warsaw <ba...@python.org> wrote: > On Jul 26, 2017, at 00:29, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> At the PEP 394 level, what I'd personally like to see us do is to >> split the "Recommendations" section into two separate sections: >> "Python User Recommendations" and "Platform Publisher Recommendations” > > I’d like to keep PEP 394 as short and proscriptive as possible. I’ve always > read PEP 394 as being aimed at “platform publisher recommendations”, i.e. > distributions who provide. I think a user guide would make a good companion > (i.e. separate) PEP.
Until yesterday I would have said the same thing regarding the current contents of PEP 394, but a surprisingly large number of the points in the new user recommendations section actually came from the current text of PEP 394 - they're down at the end of the recommendations section, and when they were all in one list, it was easy to miss that we'd crossed over from "Advice to platform publishers" into "Advice for platform users". >> For Fedora for example, we think that dropping "/usr/bin/python" from >> the repositories entirely would be too large of a compatibility break, >> whereas we're comfortable with the idea that by 2020, it will be >> reasonable to require that anything still running in "/usr/bin/python" >> be hybrid Python 2/3 code, such that finally changing the default >> won't cause too much immediate breakage (and for things that do still >> break, the recommended fix will be code modernisation to get into the >> hybrid subset prior to upgrading the OS). > > I like recommending /usr/bin/python be bilingual, but I’m wondering how > you’ll enforce this, and what the implication is for running that at the > command line. Again, that gets to the UI/UX issue. We're still working on the details (see https://fedoraproject.org/wiki/User:Ncoghlan/Default_python_module for my current notes), but what I'm currently leaning towards advocating at the Fedora level is: - we declare "/usr/bin/env python" and other environment aware invocations as already being effectively addressed, thanks to venv, environment modules, conda, and other existing PATH based solutions that change the interactive meaning of "python" - by some suitable mechanism, we offer 3 different configurations for the absolute "/usr/bin/python" path: symlink to /usr/bin/python2, symlink to /usr/bin/python3, and "Not configured yet, here's how to select your default interpreter" (as a matter of UX, I'm beginning to think we'll need to make the last one an actual installable script in its own right, as the default interpreter not found error from the shebang handler isn't particularly informative) In that light, it may make sense to more explicitly focus the PEP 394 recommendations on *absolute* invocations that *don't* rely on PATH. Right now it still talks solely about the environment dependent "python", "python2" and "python3" commands, when the actual unsolved problem is specifically the handling of the absolute "/usr/bin/python" path: - on non-Linux Unix-like systems, that path may not be present at all (see https://rubenerd.com/python-path-for-ansible/ ) - even on Linux systems, using the absolute path bypasses (by design) any PATH changes in the current environment Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
