[PEAK] eggs with individual .pth's

[Phillip J. Eby]

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.