Re: handling /usr/local/lib/python2.x/site-packages in sys.path
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/
Reply to: