[Distutils] Experience of setuptools' cache design

[Jim Fulton]

On Jan 18, 2008, at 1:55 PM, Phillip J. Eby wrote:
...
>>  It doesn't appear to be compatible
>> with multi-version installs.
>
> It *can* be compatible, with certain limitations.

I don't see how, unless you mean that only one version is handled this  
way.

>>  Also, if a newer egg version removes a
>> file, the removed file will be left installed after an upgrade.  If
>> two eggs provide the same file, files will be overridden. Admittedly,
>> this is a somewhat pathological case, but the overriding seems to
>> compound the pathology.
>
> Again, this is all true without eggs now.  Clearly, eggs have  
> spoiled you tremendously.  ;-)

Absolutely. No kidding. Eggs are great!

> Seriously, though, if buildout is tracking what files get installed  
> or overwritten during unzipping, you can manage all of this, just as  
> you presumably do for any other sort of installation recipe, no?

It isn't possible if different parts need different versions.  If I  
ignore multi-version requirements, then I could keep track of files  
installed.

In addition, a nice feature of buildouts is that you can share egg  
directories between buildouts. This is very handy, but makes multi- 
version support even more important.

>> As described in a separate thread, I'm going to add an option to
>> buildout so buildout users can explicitly define a directory to use  
>> as
>> a setuptools cache.  In that case, zip-safe eggs can remain zipped
>> even if they have extensions.
>
> If you want to be really safe/careful, you can pre-extract the eggs  
> to the cache, thereby avoiding any runtime permission problems.

Yup, except I don't see a way to enumerate the resources.  After all,  
resources aren't listed in the egg meta data. I could make an educated  
guess and extract all of the non-py files. Or I guess I could just  
extract everything. :)  Disk space is pretty cheap, so this is really  
quite practical IMO.

JIm

--
Jim Fulton
Zope Corporation