[Python-Dev] vendor-packages directory

Phillip J. Eby pje at telecommunity.com
Thu Sep 22 22:35:45 CEST 2005

At 01:18 PM 9/22/2005 -0700, Rich Burridge wrote:
>Phillip J. Eby wrote:
>>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.
>Bob Ippolito wrote:
> > vendor-packages.pth should look like this (evil, but practical):
> >
> > import site; site.addsitedir('/usr/lib/python2.4/vendor-packages')
> >
> > Otherwise packages like Numeric, PIL, PyObjC, etc. that take  advantage
> > of pth files will not work when installed to that location.
>Thanks!  I'll work with the architectural committee in question to see if they
>are happy with this approach to solving the problem.

Glad we could help.  Unfortunately, there isn't any sort of document at the 
moment for "Python Distributors" to help explain how these kinds of 
problems should be solved.  It would probably be a good idea for us to have 
one.  Perhaps a volunteer or two could be found on the distutils-SIG who 
could help put one together, since a certain number of distributions' 
Python gurus tend to hang out there.

(By the way, assuming this solves your problem fully, don't forget to 
withdraw your patch on SF, optionally citing the python.org archive URL for 
this email.)

More information about the Python-Dev mailing list