-----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]

Reply via email to