-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 11, 2008, at 3:43 AM, Matthias Klose wrote:
Currently Debian's python has /usr/local/lib/python2.x/site-packages
in sys.path allowing for installation of local modules. Barry did
point out that this conflicts with a python installation, where
/usr/local is the default prefix, and the system python gets modules
from the local installation. Some suggestions were made to fix this:
- add an env var to not include /usr/local/lib/python2.x/site-packages
when the env var is set. Keeps standard behaviour without
modifications and allows people to remove it from sys.path. But
requires the user to know about that option.
- add another path (e.g. /usr/local/python/lib2.x/site-packages),
and remove the /usr/local/lib/python2.x/site-packages path after
the next release. Does provide an upgrade path, but doesn't solve
the probem immediately.
Thanks for raising this issue Matthias. There are a couple of other
points I'd like to make.
This isn't /just/ a problem for Python experts or developers.
Sometimes we recommend that Ordinary Users install Python from source,
say to use an application that isn't supported by a distro's packaging
system. There can be lots of reasons for this: maybe the app is in
beta testing, maybe they want to try things out without affecting the
system version, etc.
Python developers may not be Debian experts and may not know about
this system peculiarity. So when we tell people "just do configure;
make; make install" we can actually do inadvertent damage to their
Debian system.
It also makes Debian the odd man out. Instructions we publish for
every other *nix have to have a caveat or FAQ for Debian's (and
derivatives) difference. These can go unnoticed until things break,
and then we can get difficult to debug problem reports. An
experienced helper will be conditioned to first ask "Are you on Debian
or Ubuntu? Well, you have to do things differently there."
This feature is difficult to discover, and highly surprising to any
Python person, especially more so if they are not Debian experts.
When I first hit this problem (and complained to Matthias ;), it took
me several hours to figure out what was going on, where the hack was
being inserted, and that it was actually intentional.
A more fundamental question though is, why do this in the first
place? What's the use case? What convenience are you providing
users, and if that's overwhelmingly beneficial, can it be done in a
way that doesn't go counter to the conventions of the upstream project?
What confuses me is that this doesn't appear to be a convenience based
on permissions, because on my Ubuntu box it takes root to install
things in /usr/local just as it would to install things in /usr.
Meaning, if I'm going to install an egg in either location, either
manually or via easy_install, I still need to be root. Although this
doesn't affect things /now/ I think Python 2.6 will allow for user-
specific sys.paths so that you could for example install an egg in
~/.local/lib/python2.6 and have it just show up.
I'm also uncomfortable with the way that Debian accomplishes this: it
hacks Python's standard site.py. There really should be a better way
to do this (I have to think about this a bit though).
I would opt for Matthias's second option, and would be happy if there
was a roadmap for fixing this problem.
- -Barry
P.S. System applications written in Python should /never/ use "#! /usr/
bin/env python". They should always hardcode /usr/bin/pythonX.Y.
Otherwise you can break your system just by tweaking your $PATH. You
should have to work harder to break your system <wink>.
This is why setuptools rewrites the #! line when it installs scripts
in packages.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR9aM8XEjvBPtnXfVAQKpBwP+OBvovf+MZsHTsU5N42TKqqHXi+IQwHKp
rnCtqkBju+jYAWmJpE5BWHmYkBIyc9Me4N7tPMM04YYKwipub5tLEa1CUaHmtyWp
5sEHK2rlOJoluBvJy/S2NBgkSExw2RHmgkn5ZUb8IlLHO9HFh67Egc6vWG6Bg6xq
GScfgB1bEfQ=
=yk2u
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]