On Sat, Apr 19, 2008 at 09:05:12AM +1000, Ben Finney wrote:
> Floris Bruynooghe <[EMAIL PROTECTED]> writes:
>
> > I think it would be really good if we could agree on a simple
> > solution for this problem. However I haven't really seen an
> > agreement come out of this thread. So far what (I think) some
> > proposed solutions are:
> >
> > 1 Have a different path in /usr/local (not
> > /usr/local/lib/pythonX.Y/site-packages) to augment the system
> > sys.path with.
> >
> > 2 Make sure /usr/local is near the end of the sys.path so system apps
> > won't break due to it (currently
> > /usr/local/lib/pythonX.Y/site-packages appears before
> > /usr/lib/pythonX.Y/site-packages on my system, not sure if this is
> > normal and if not who's fault that is).
>
> These both appear to be addressing the issue that customisations (of
> the form "install a new Python package") in '/usr/local' can disrupt
> the behaviour of system tools using Python.
>
> So, here's my proposed solution:
>
> Provide a simple way for a Python program or instance to specify
> "don't have '/usr/local' in the 'sys.path'". Recommend that the system
> Python tools use this feature to ignore '/usr/local'. Continue using
> '/usr/local' for custom site-local packages.
Seems hard. While it might be feasable for apps (who will live in
known directories) it becomes a lot harder when random applications
ship python scripts in some random directory, e.g. cgi-bin or so. It
basically means that a large amount of packages in a distro will
always be broken to this effect until somone stumbles over this
particular bug for this particular package and happens to be good
enough to file that bug. It's the same problem as with requiring
system packages to use a separate python installation with a more
strictly pinned sys.path.
> That is, if we're talking about the system Python tools being the
> unusual case ("don't want site-local custom packages"), then that's
> where the focus should be on allowing for that special case.
So most people here don't like Debian's and SUSE's behaviour, that's
sad but anyway, which means 1 above --introducing a new Python
endorsed site-packages dir in /usr/local-- seems unlikely.
Since 2 above --making sure /usr/local is at the end of sys.path-- can
be done entirely by the distributions who like /usr/local on sys.path
this seems like the best option. In Debian this is currently
implemented by adding /usr/local/ to the prefixes of site.py, ensuring
that .pth files in /usr/local are still usable.
So just to err on the side of safety: can anyone think of a reason
that having /usr/local/lib/pythonX.Y/site-packages/ at the end of
sys.path in this way could cause problems?
Thanks
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
