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 <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
