[Distutils] Experience of setuptools' cache design

[Jim Fulton]

On Jan 18, 2008, at 5:34 AM, Viktor Fougstedt wrote:
...
> My thoughts (perhaps useful, perhaps not):
>
> * Primarly, I think it is unfortunate that an "import foo" starts
> creating files in the file system - it is not what I personally
> expect from doing an "import"!
>
> * On our user system, with some 20.000 active users, there will be up
> to 20.000 copies of a .python-eggs directory if someone installs a
> program that uses a Python Egg (but does not have access to site-
> packages or does not know how to detect what eggs are used and how to
> install them there).
>
> * I, personally, think it would be better if I explicitly have to
> _request_ a per-user cache directory being made, rather than needing
> to implement solutions to _prevent_ that from happening.
>
> * If the default is to remain to create files on "import", I would
> like error checking and fall backs. If the cache directory cannot be
> created in $HOME, I would like the code to create it somewhere else
> (or not at all) instead of giving me an exception. As end user I did
> not request the cache-directory to be made, and therefore do not want
> to be given an exception caused by it not being created. Especially
> as I do not know what to do with such an exception. Perhaps creating
> it in /tmp/python-eggs-$USERNAME, for example.


I couldn't agree more. And, AFAICT, everyone I know, except Phillip,  
agrees that this is a bad feature.

IMO, any package including extensions should be treated as zip- 
unsafe.  I intend to add this policy to buildout.  Then the only way  
to be bitten is to use one of the resource APIs that causes files to  
be extracted from zipped eggs. I'm happy to consider calls to these  
APIs to be bugs.

As a work around, when installing packages that have this problem, use  
the -Z option to easy_install to cause them to be installed unzipped  
(or unzip them yourself).

Jim

--
Jim Fulton
Zope Corporation