Re: handling /usr/local/lib/python2.x/site-packages in sys.path
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.
In other words you are trying to make things a bit easier for people who are
a) expert enough to build and use their own python version and b) notice
things breaking because they use a site-packages path which is also used by
the system python.
I can sympathise with building your own python (Debian's python uses twice
the amount of memory needed for most unicode-using applications due to the
use of UCS4 for example) but I think people who know enough to do that also
know enough to deal with the resulting possible conflict over
/usr/local/lib/python2.x use. Personally I have a number of local python's
but they are all isolated in zc.buildout instances.
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.
That makes things unpredicatable: use su or something else that can affect
the environment and suddenly python behaves quite differently. That does not
feel like a good idea.
- 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.
That just means you will break people's python at a later point again. That
certainly can not be the right thing to do.
Iff we really must come up with a way to make it a bit easier for people to
install their own python version make it a system-wide switch in
/etc/default/python2.x and keep the default behaviour as it is now so you
will not break existing installations.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Reply to: