shebang line modified by setuptools
![](https://secure.gravatar.com/avatar/2e321cc0efe9422d37165e922298494e.jpg?s=120&d=mm&r=g)
Sorry for breaking up the thread. I wasn't subscribed to the list (now I am) and apparently I stopped being CC'd at some point, so I'll have to sum up several things and address them here. 1) I agree that "system" scripts should use the "system" python (whatever that is defined to mean - for now it means /usr/bin/python) and that path should be hardcoded into the shebang line. 2) I disagree with Ben's position that: """ It's my position that the Python instance one uses for development should diverge as little as possible from the default system instance. Otherwise one is actively pursuing a recipe for dependency failures when one eventually deploys the result. """ The reason I disagree is that assumes the system is single user and/or single purpose. In my case (and many others) I'm concerned about a traditional shared hosting environment (not VPS). This means that there may be several versions of Python (and many, many ~/python2.x/site-packages directories). Diverging from the default system instance *in every single case* is the only way to make this workable. Not only do different accounts require a particular version of Python, but they require particular versions of installed packages (one might rely on Pylons 0.9.5 another on Pylons 0.9.7). 3) Since there is so much opposition to using /usr/bin/env in the shebang line, an acceptable alternative would be to hardcode the version-specific python instead (e.g. /usr/bin/python2.4). This seems to solve my particular issue while respecting Phillip's concerns about accidentally running an incorrect interpreter, and actually does a better job since Phillip's method (using /usr/bin/python) falsely assumes that the system Python will never change (untrue on Gentoo, Foresight, SourceMage and any other distro that supports "rolling upgrades"). 4) As far as the discussion about having three separate install areas, I think this is not necessary since it's already possible to have unlimited install areas (one per user) using features already built into setuptools. /usr/bin/python/ and /usr/local/bin/pythonX.X/ should suffice. If setuptools used versioning info along with a hardcoded path in the shebang line, this would become even more solid. I should also mention that some of this discussion is being made moot by virtualenv. I'll be using that for future stuff, but I have legacy installs to worry about as well. Regards, Cliff
participants (1)
-
Cliff Wells