On Mon, 2017-07-31 at 00:02 +1000, Nick Coghlan wrote: > On 30 July 2017 at 07:57, Björn Persson <Bjorn@rombobjörn.se> wrote: > > Mathieu Bridon <bochecha@xxxxxxxxxxx> wrote: > > > To be honest, given how much energy is spent on this migration > > > for a very low gain, it makes me feel like having an unversioned > > > "python" (whether as package or executable names) was a mistake > > > we should let disappear with Python 2. > > > > I agree. > > > > From an emotional point of view I fully understand the Python > > folks' desire to have "Python" mean Python 3, and that's fine in > > marketing contexts such as websites. > > While I'm a CPython core dev in addition to being a RHEL developer, > it's mainly the latter role that leads me to consider the status quo > in Fedora as being rather problematic :) > > > But filenames and package names are technical > > identifiers. They must be chosen so that they'll fulfil their > > functions, and with consideration for forward and backward > > compatibility. > > Right. Unfortunately, the folks saying "just use /usr/bin/python3 in > your shebang lines" are choosing to ignore systems that don't have, > and *aren't going to get* a Python 3 installation. Even if Red Hat > were to start making a native Python 3 stack available, there would > still be an awful lot of EL6 and EL7 systems around where that stack > isn't going to be installed. Sure, but nobody is telling everybody to use /usr/bin/python3 in their shebang line. I started this subthread saying everybody should just use the versioned executable in their shebang line. Whether that's Python 2 or 3 depends on what's available on their system and what they are targetting. > So that's effectively a hard design constraint for me: folks > targeting EL6 and EL7 *are* going to have to use "/usr/bin/python" in > their shebang lines (since they can't even assume "/usr/bin/python2" > will be present, Wait, what? I see /usr/bin/python2 in the EL7 spec file: https://git.centos.org/blob/rpms!python.git/c7/SPECS!python.spec#L2041 I'm pretty sure I had /usr/bin/python2 back in the days when I was using EL6. (but I have no way to check that now) > let alone "/usr/bin/python3"), so I have to assume that "just tell > Red Hat's customers to change all their Python shebang lines to > require Python 3" isn't one of the design options I have available to > me. And again, nobody in this subthread suggested moving things to Python 3. > That means the only degrees of freedom I/we potentially have are > related to what "/usr/bin/python" means in Fedora. The status quo is > that by default such scripts simply break, and if you want them to > work, you have to install the full Python 2.7 stack. Which, again, is what happens for other shebang lines like /usr/bin/zsh or /usr/bin/ruby. Having to install the stack needed by your custom-built tools seem like a perfectly normal thing to me. > If you want to do anything else, you have to resort to creating > symlinks manually, and as soon as you do, your system is in an > unsupported configuration, so if it breaks, any bugs you file are > just going to be closed as "not a bug". > > Accordingly, my proposal is that we support *3* admin selectable > configurations That seems like a recipe for confusion. How does one know what /usr/bin/python actually is if it can change from one machine to another? > > Providing an unversioned "python" serves only to lure incautious > > programmers into using it where they should use a versioned name. > > My aim is for folks to start thinking of a "/usr/bin/python" shebang > as being akin to writing "/bin/sh" instead of "/bin/bash": as the > author of the script, by deciding not to explicitly qualify your > shebang line you're saying "I'm not writing in either Python 2 *or* > Python 3, I'm writing in the hybrid subset of both of them". There > aren't many good reasons for a script in a distro package to do that > (they should just depend on the stack they want), but there are > plenty of good reasons for multi-distro scripts to be written that > way. > > As time goes by, I'd expect the meaning of the unqualified variant to > shift slightly such that "/usr/bin/python" is taken to mean "written > in the oldest Python dialect that is still actively supported by > upstream and/or commercial vendors (or potentially even older than > that)" while "/usr/bin/python3" retains its current meaning of "run > in the default Python 3 stack" (with the two links thus becoming > functionally equivalent for systems that only have one Python stack > installed). I can't see admins testing their scripts on multiple Python version. A lot of us Python developers already don't want to bother with that, and just target one or another. :) (or something like Python >= 3.4) In case I wasn't clear, my proposal when I began this subthread was: * have the versioned /usr/bin/pythonX for each major version of Python we support; * /usr/bin/python will remain a symlink to /usr/bin/python2 forever, as long as we decide to keep a Python 2 stack in Fedora, and after that it would just disappear; This means that existing scripts using /usr/bin/python as a shebang will keep working as long as we have Python 2 in Fedora, we won't break them by switching what Python version is pointed to by the symlink. It also means people wanting to move their script to Python 3 will just opt-in to it by using the /usr/bin/python3 shebang, after which their script will always run on Python 3. When Python 4 comes in, we'd introduce /usr/bin/python4 and people would have their script keep working on Python 3, until they are ready to port them and opt-in to Python 4 by switching their shebang line. After all, "explicit is better than implicit". ;) -- Mathieu _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
