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

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to