On 1 September 2016 at 22:04, Avram Lubkin <aviso(a)rockhopper.net> wrote:
On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan <ncoghlan(a)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 | ncoghlan(a)gmail.com | Brisbane, Australia