On 1 September 2016 at 22:04, Avram Lubkin <av...@rockhopper.net> wrote: > > On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> >> The ideal point we'd like to get to is one where all distro provided >> scripts actually have the appropriate major version in their shebang >> lines, and the unqualifed "python" is something along the lines of a >> user-configurable launcher, akin to the "py" launcher for Windows: >> https://docs.python.org/3/using/windows.html#python-launcher-for-windows >> (see https://www.python.org/dev/peps/pep-0397/ for more details on >> that) > > > While I see some benefit to something like this and could see use cases for > including it in the shebang, it would be overkill for "/usr/bin/python". > Windows needs something like that because it doesn't support symlinks.
This isn't about Windows, this is about making Fedora a sufficiently user friendly platform for Python developers that they don't feel obliged to reach for third party runtime managers like pyenv and conda (which, make no mistake, a great many of them already do). We (wearing my upstream CPython hat for this post) would like developer focused Linux distros to either put individual end users fully in control of what happens when they type "python" at the shell (or run a script with "#!/usr/bin/python" as its shebang line), or at least give system administrators the ability to configure that on a per-user basis. (There are some other commands like pypy and ipython that could use a similar treatment, but if we can solve this for CPython, then it becomes easier to apply a similar solution in other contexts) One key advantage this approach offers is that system administrators can upgrade selected users to "Python 3 by default", while still keeping Python 2 as the default for their own accounts and for service accounts (e.g. Ansible's remote access). "You must upgrade entire systems to Python 3 all at once" simply doesn't give people enough granularity to do a properly managed transition (cf. the Ansible bootstrapping problems when Python 2 was first dropped from the Fedora base install). Folks that don't want the behaviour of their scripts to be dependent on a per-user settting should be using the symlinks qualified with the major version rather than the unqualified path (which is already the recommendation in PEP 394, and has been for years, since the meaning of an unqualified Python reference can vary by distro). > Let's stop trying to reinvent the wheel. There is already a system for > handling this, alternatives, which is used by other languages and included > in a minimal Fedora install. Unfortunately, the alternatives system also requires administrator access to configure and is also a global setting affecting the entire system, so it doesn't solve the fundamental usability problem associated with neither individual users nor system administrators being able to reliably configure different options for what particular users get when they type "python" into a shell session or run a script with "/usr/bin/python" in the shebang line. (Hence the line in https://lwn.net/Articles/640296/ about "The 'alternatives' mechanism is another possibility, but that makes more sense for things like choosing an editor than it does for choosing a version of Python.") I'll acknowledge that putting `python` under alternatives would be *better* than the status quo of having it globally locked to a distro-defined version (since it would at least get us to "admins in control", even thought it doesn't get us all the way to putting the user in control of their own developer experience), but it still gets the user experience wrong, as a particular group of users shouldn't have to have a shared definition of what 'python' means just because they all have accounts on the same server, or run on the same Standard Operating Environment. ? It would only require adding to the %post and > %postun scripts in the spec file and allows very easy testing to see what > breaks when changing the default. When we are ready to change the default, > only one value needs to be changed. And most importantly, it gives the > end-user an easy way to change their system-wide default either from python > 2 to 3 or when running a pre-release version of 3.x in parallel. Switching to putting /usr/bin/python under alternatives would definitely be a better option than unilaterally switching it to Python 3. However, I'm also confident that it wouldn't be a significant enough change to slow the rate of adoption of non-distro Python versions, such as those published for pyenv and conda (note that my assumption is that we have a shared goal of wanting Python developers to find value in using the Fedora curated Python runtime binaries over those provided by other distros, or by distro-independent publishers). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
