On Mar 13, 2015, at 05:00 AM, Bohuslav Kabrda wrote:
+1, the system scripts should use system Python explicitly to keep working when user's environment changes. I'm not sure about Debian/Ubuntu, but we do this in Fedora as much as we can.
We do this in Debian/Ubuntu too, although it looks like there are one or two outliers so they probably aren't built with the common Python build tools.
And while I'm primarily a packager, I also use /usr/bin/env python[2|3] while coding, because it's just more handy during development.
Oh, definitely.
For more than a year now, I've been trying to push python 3 as default in Fedora. "Default" means that it should be the only Python on live media/cloud images/... and various system applications and system scripts will run on it.
This is a great goal, and something that we've been working toward in Debian/Ubuntu also. I hope all the Linux distros can do the same thing.
I want Fedora to follow PEP 394, so this doesn't mean switching /usr/bin/python to Python 3, but that's one of the biggest sources of confusion. Most users expect /usr/bin/python to point to "the" Python.
This is what we need to tease out I think. For the most part, users don't care what the shebang line of their scripts is, or even if they have one. They *do* care about what interpreter fires up when they type `python` or any of the variants at their shell, as well as...
3) Custom user/sysadmin scripts pointing to /usr/bin/python
[...]
Point 3 is the real issue, because (from my experience) there are tons of users/sysadmins that use Python as a shell with nice features and don't really care about what's going on in Python upstream. These scripts are outside of Python upstream and distro control and we can't do anything about them. My thinking is that these won't change - not now, not in two years, not in ten years. The only way to change them is to break them - and then the real question is: do we want to break them or do we want to keep them working forever? (well, at least until we retire Python 2, which would make /usr/bin/python disappear completely)
That is indeed the question. I think if we break them, we're just pissing people off for a not compelling enough reason (notice I didn't say "good" reason :). It think the first step is to strongly encourage people to start using /usr/bin/python2 for their Python 2 scripts, and to strongly encourage all distributions of Python to be including a 'python2' symlink. Of course, for anyone with even a rudimentary understanding of *nix, it's easy enough to create that symlink if it's missing, but we might even go a step further and include a 'fix_py2_usr_bin' script that people can run which wouldn't do anything more than ensure /usr/bin/python2 exists. We've committed to bug fix releases for 2.7 until 2020. To me, that's the time frame for any change to /usr/bin/python, whether that's complete removal or repointing the symlink. By then, we'll have 5 more years of educating people to be using 'python2' and 'python3' explicitly so the impact of resolving the ambiguity around 'python' should be lessened. Cheers, -Barry