Comment 10 for bug 912625

Marc: Fair enough. I guess the same kind of hijacking I mentioned could be accomplished in a lot of ways, including setting PYTHONPATH, so it's probably alright.

Scott: The Debian policy reads:

> Maintainers should not override the Debian Python interpreter using /usr/bin/env

The word "should" is somewhat ambiguous in its level of severity, but I would read that as a "strongly discouraged" even if not a hard and fast "you must not do this". I would say there ought to be a really good reason if a system-installed executable is figuring out which interpreter to use at runtime.

> You shouldn't put a non-system python in your system's python path.

I assume you mean on your shell's PATH as the PYTHONPATH is something different -- at any rate, this is an unworkable demand for just about anyone who does anything resembling serious Python development. In addition to virtualenv being a ubiquitous tool for deployment management and environment isolation, several specialized Python distributions exist (both commercial and FLOSS) such as Enthought Python Distribution, ActivePython, FEMhub, Sage, etc. and isolate themselves from the system Python (as they should).

Placing the bin directory of one of these distributions, or of a virtualenv, on your shell's PATH (i.e. adding it to your PATH in ~/.bash_profile) should not cause random system-installed executable scripts to start breaking, and I would very much consider it a bug in the package that installed the executable if this does happen.

Furthermore, most of the Python scripts in /usr/bin on my machine follow the "hard code which interpreter you want" convention, and as Barry pointed out above, even the native Python packaging system, broken as it is in many ways, performs this kind of munging. I would consider this a strong case for not using #!/usr/bin/env python.