Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When you have several Python programs, where does /usr/bin/python point to?

I must admit, that I did not think to much about it until now, but normally there is only /usr/bin/python in the scripts.

Of course, if everybody has /usr/bin/python3 inside his Python3 programs, everything could work (unless some of your apps need special environment vars like PYTHONPATH, what could make it troublesome again).

But still, the standard installation of Debian (and others, as much I know) does not include Python3 by default, you at least have to add it to your installation. That is something, you must tell your customers, when you ship Python3 programs.



/usr/bin/python should never point to Python 3. Because of the compatibility break, the convention (and default for the Python build scripts) is to always name the Python 3 binary python3, so there should be no conflict. It's understood that during the (very long) transition period there will be need to run both side by side.

A handful of ditros have gone ahead and named it python anyway. A stated motivation has been to encourage adoption of Python 3, but practically they're just shooting themselves and their users in the foot, and ensuring incompatibility with the shebangs defined for every other OS. (I don't think there's any plan to ever switch the default binary name from python3 to python, so this incompatibility may never be resolved.)


Arch switched from Python 2 to Python 3, keeping the /usr/bin/python binary as pointing to their newest version of Python before the convention of naming it /usr/bin/python3 was standardised.

It was specifically in response to the troubles caused by having /usr/bin/python be python3 in Arch that the guideline came about: http://legacy.python.org/dev/peps/pep-0394/


Thanks for the reference; I somehow failed to find the origin of this convention in previous searches.


Most package managers allow you to specify a dependency on Python 3, so you shouldn't even need to tell your customers. Otherwise, you can always use virtualenv and ship Python with your code.

And yes, if you're targeting Debian or Debian-like systems, make a deb. It's really not that hard, especially with newer tools like fpm.


Thank you for mentioning fpm, I'd never heard of it and often wished for something like it. Commenting to bring attention to it, and so I don't forget!


> When you have several Python programs, where does /usr/bin/python point to?

/usr/bin/python should always point to python 2 (or nothing) /usr/bin/python2 should always point to python 2 (or nothing) /usr/bin/python3 should always point to python 3 (or nothing)

scripts using a shebang line should not, however, rely on /usr/bin/python pointing to python2, and should only use it when they are source-compatible with both python2 and python3.

http://legacy.python.org/dev/peps/pep-0394/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: