Matthias Klose wrote: > - 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.
I would much prefer this. Debian users with local (=unpackaged) packages are probably much more common than Debian users with (=unpackaged) versions of all python, and I would rather reasonably support those than leaving them in the cold. Quite frankly, installing stuff that is also present in the system under user local is a recipe for disaster (also happens with libraries) and rather hard to cater for. > - 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. No. Let's not break stuff for people that use the software in Debian that they got from Debian. Quite frankly, the use case seems a bit of bad practice. Installing to /usr/local software to compete with that in /usr leads to all sorts of breakage where one doesn't expect it and if python.org needs people to install experimental versions they should either recommend chroots / test machines or provide packages. Anyone capable of installing a local version of python is also able to run debootstrap to create a chroot. Kind regards T. (who used to maintain a set of libraries where local installations caused no end of trouble for users, maintainers, and upstreams) -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
