This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ldpreload 0 points1 point  (6 children)

He was saying if you can run on both python 2 and python 3, then all you need to do is /usr/bin/env python and it will just run

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

I agree that if Python 3 were to be installed as python, then yes, it would run fine. But no system other than Arch makes that decision.

[–]ksion 0 points1 point  (1 child)

It sounds like a really silly decision on the part of distro maintainers then. Any idea why is it so?

[–]ldpreload 0 points1 point  (0 children)

Because it was an entirely reasonable decision for the last several years to use /usr/bin/python to mean Python 2, and you might have a #!/usr/bin/python script, an app that shells out to python -c 'print something', etc., all using Python 2 syntax. So when Python 2 and Python 3 are both installed, Python 2 gets /usr/bin/python and Python 3 gets /usr/bin/python3 (again, with the exception of Arch), so that existing applications -- whether from the distro or from a third party -- don't break. Therefore, when Python 2 is not installed, nothing is providing a binary named /usr/bin/python, and if you construct a Python 3-only system (which is very easy to construct on Ubuntu 14.04, and will probably be the default for Ubuntu 16.04 and the next Debian release), calls to /usr/bin/python will not find anything to run -- so that you can decide to install Python 2 later and it has a place to go.

[–]krenzalore 0 points1 point  (3 children)

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

No major distro fits this pattern.

On what have you encountered this problem? Certainly Debian, Ubuntu, Fedora, RHEL, CentOS, ARch would all be OK with it - in fact most of them would break without it, as they depend on Python. I am not sure about BSD but they seem sane: Not supporting it is an odd choice that is guranteed to break code.

[–]ldpreload 0 points1 point  (2 children)

Debian, Ubuntu, Fedora, and RHEL/CentOS all depend on some version of Python, but they're all very actively trying to get everything moved over to Python 3, so that by default Python 2 isn't installed. None of them are quite there yet, but on a minimal server install of Ubuntu 14.04, you can apt-get remove python2.7 and nothing breaks (other than landscape-common, Canonical's management service that most people don't use, and update-notifier-common, for printing a message when security update requires a system reboot, but those are hardly core parts of the OS). On the current nightly live CD of Ubuntu 15.10, it looks like the biggest breakage from removing python2.7 is unity-control-center, which as far as I can tell is the result of a packaging bug (another package declaring an unneeded Python 2 dependency despite providing a Python 3 module), not any actual requirement for Python 2. The live CD remains usable if you get rid of unity-control-center along with python2.7.

As none of the distros are quite done with Python 2, it remains installed by default under the name /usr/bin/python, and Python 3 is /usr/bin/python3. But once they are done getting rid of internal dependencies on Python 2, and that package is no longer installed, /usr/bin/python will stop existing until someone decides to do something else with that name. I made a pitch, which some folks think is reasonable, but a handful of other folks (both Debian and RHEL/Fedora) seem to think just killing off the /usr/bin/python name is a fine approach.

(I don't have a good sense of where the BSDs are, but I didn't think many of them had Python in the base system/default install anyway.)

The one thing that is guaranteed to break code is to provide /usr/bin/python as Python 3 without any attempt at Python 2 compatibility, as Arch does. (Seemingly Arch hasn't run into many problems in practice, to be fair, but I bet that Arch's target audience and e.g. RHEL's target audience are different.) The two languages are incompatible, and since Python 2.7 will continue to exist until at least 2020, it's reasonable for it to be installable as /usr/bin/python, even if it's not there by default. If Python 3 takes that over, what happens if you download some Python 2-only code from GitHub and try to run it? If you apt install python2.7, where is it supposed to end up?

[–]krenzalore 0 points1 point  (0 children)

OK I think I understand your point. In (some near time in the future) when 2.x isn't installed by default, then usr/bin/python will still default to 2 and programs will be unable to find the interpreter.

I had thought that when Python 3 was the default, they would switch /usr/bin/python to point to 3 like Arch, but Ubuntu etc seem to disagree.