[Python-Dev] vendor-packages directory
Phillip J. Eby
pje at telecommunity.com
Thu Sep 22 21:56:35 CEST 2005
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:
>>>for the full reasoning behind this request, and the replies
>>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
>as supplied by the vendor (Sun, Apple, RedHat ...) with their operating
>software, should go in a totally separate base directory, to differentiate
>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:
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.
More information about the Python-Dev