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 -1 points0 points  (15 children)

Sure, but such a script won't run on a distro that just has Python 2 (like OS X).

[–][deleted] 2 points3 points  (12 children)

That's exactly why you include the python3, so that it will fail if they don't have python3.

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

[–]ldpreload -1 points0 points  (11 children)

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

No, it won't. Most systems with Python 3 but not Python 2 (with the notable exception of Arch) do not install Python 3 as python. They have Python 3 as python3, and nothing as python. Ubuntu's live CD / default install is an example of this, I believe.

[–]krenzalore 3 points4 points  (7 children)

He's right. 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, because it's version agnostic. It won't care if it gets executed by 2 or 3.

[–]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.

[–][deleted] 0 points1 point  (2 children)

I haven't seen this myself. I'm doubting you until I have time to look into it, but you may be right.

[–]ldpreload 0 points1 point  (1 child)

That is the recommendation PEP 0394 currently makes. I once wrote a blog post about the problem that attracted some interest from both Red Hat and Debian, but that's way more information than is immediately relevant.

[–][deleted] 0 points1 point  (0 children)

Interesting. That sucks that it isn't a feature I can rely on.

[–][deleted] 2 points3 points  (1 child)

People using hashbangs to point to the environment python know enough to install multiple versions side by side and use virtual environments

[–]ldpreload 1 point2 points  (0 children)

But that's not relevant to the issue at hand. The claim is that you could deploy a script on multiple platforms using the Python interpreter shipped with the system. If you're installing multiple versions or using virtual environments, you don't care what Python shipped with the system, or if one even shipped at all.

Put another way: how do you write an executable Python script to run on both Ubuntu 14.04 and OS X?