[PEAK] eggs with individual .pth's
Phillip J. Eby
pje at telecommunity.com
Thu Oct 13 18:31:42 EDT 2005
At 01:18 PM 10/13/2005 -0700, Rob Cakebread wrote:
>Phillip J. Eby wrote:
>>At 02:07 PM 10/12/2005 -0700, Rob Cakebread wrote:
>>>Would using individual .pth files be a problem as far as using
>>>easy_install as a query tool or breaking other features it may have?
>>The impacts are:
>>1. Slower Python startup time, since Python must open and read all .pth files
>Thanks for the quick reply, Phillip.
No problem; I'm glad that you're contacting me to help make sure that
there's a good packaging policy for eggs.
>We did some preliminary testing and
>it wasn't much slower, but we'll do more testing.
Keep in mind that it's an extra open for *each* .pth file, so the overhead
of having say, 20 eggs installed will give you an overhead 20 times higher
than that of one.
>>2. Some packages may not be overrideable via easy-install.pth, as .pth
>>files are read alphabetically. (You could work around this by using
>>names like vendor-foopackage.pth, which would then allow easy-install.pth
>>to override them)
>I'm not sure what you mean here. In what situation would we want one
>.pth to override another .pth?
Well, you might not want it, but a user who's trying to install a later
version of something than what's packaged would. For example, imagine a
user who's developing the next version of the AcmeThing package, and has
the stable version also installed. By running "sudo setup.py develop" they
can update easy-install.pth to point to their under-development
version. But if the vendor .pth file is 'AcmeThing.pth', it'll be read
before 'easy-install.pth' and will thus prevent them from overriding it.
Arguably, there are other ways to do the overriding, but they're more of a
pain for the user or developer. Note too that it's not just developers
who'd have this problem: any user tracking a CVS or Subversion release of a
package would encounter the same thing.
More information about the PEAK