On Sat, Apr 19, 2008 at 09:05:12AM +1000, Ben Finney wrote:
Floris Bruynooghe
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