Ben Finney wrote: > To have a command with custom behaviour, the recommendation is the > general one: put an executable file at ‘/usr/local/bin/python’ with > whatever behaviour you want.
eeek, please don't! If a user created an incompatible /usr/local/bin/rm (didn't delete files, didn't exit 0), that would break a lot of tools and we'd tell the user not to do that. Fortunately, users don't tend to. /usr/local/bin/python is no different but for some reason users feel they can meddle with it. Do not put locally versions of system tools like 'python' in root's PATH (or indeed in any user's PATH if the user expects to be able to run packaged tools). Doing so ends up potentially breaking packaged modules (they can find the wrong versions of dependencies in /usr/local since that is also in sys.path), and packaged applications (broken modules plus perhaps now running with the wrong version of the interpreter which is either incompatible or doesn't have the necessary modules installed). There's a reasonable number of things in /usr/bin with "#!/usr/bin/env python" that would be unhappy with this configuration. We have lots of experience of this sort of breakage in #debian, where we see the this breaking maintainer scripts or packaged tools. As soon as we see a python backtrace with /usr/local in it, we know that is going to be the problem and expunging the local python installation from /usr/local is what is needed. Putting python in other places such as /opt or ~/.local would be fine; even better still is to use one of the many virtualenv approaches so you're not even leaking that incompatible interpreter into a user's default environment. (see also: please don't run pip as root) cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7