At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote:

Phillip J. Eby wrote:

...

...

Recently I asked about the inclusion of a "vendor-packages" directory for Python on the Python mailing list.

See the thread started at:

http://mail.python.org/pipermail/python-list/2005-September/300029.html

for the full reasoning behind this request, and the replies I received.

I'm with Terry on this, it needs a better rationale. Why can't you just add a .pth file to the site-packages directory? It seems that would address the issue nicely. (See http://docs.python.org/lib/module-site.html for documentation of the .pth mechanism, which would let you implement a separate vendor-packages directory without modifying Python, and would still allow local overrides of your vendor packages.)

I understand how .pth files work.

The rationale for requesting the "vendor-packages" approach, is that Python files, as supplied by the vendor (Sun, Apple, RedHat ...) with their operating system software, should go in a totally separate base directory, to differentiate them from Python files installed specifically at one site.

Right - I'm proposing you add a vendor-packages.pth file to site-pacakges, that points to a "totally separate base directory" where those files are installed, not that you install the packages themselves under site-packages. To make sure we're disagreeing about the same thing <0.5 wink>, here's what I'm suggesting: 1. Install your packages in /usr/lib/python2.4/vendor-packages (so far, so good, we agree on this part) 2. Create a 'vendor-packages.pth' file in /usr/lib/python2.4/site-packages, containing the line: /usr/lib/python2.4/vendor-packages This will ensure that your vendor-packages "just work", unless locally overridden in site-packages. So, you install one .pth file, once, as part of your installation of Python itself, and it works *now*, without waiting for a new Python release or complicating any other Python code or requiring agreement between vendors about how to do this. This is one of the things that .pth files are for, and I believe it should be the recommended way for operating systems to establish OS-specific modifications to the default Python module search path. Otherwise, everybody will be patching site.py for their specific OS, and there are already too many OS-specific things in that code, and for backward-compatibility reasons we can't get rid of them in Python 2.x. I don't think we want to add new ones.