[Distutils] Experience of setuptools' cache design

Phillip J. Eby pje at telecommunity.com
Fri Jan 18 15:49:13 CET 2008

At 11:34 AM 1/18/2008 +0100, 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"!

Note that normal imports will also create .pyc or .pyo files 
alongside the source, if a valid compiled version of the source isn't 

>* 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).

If you want eggs to always be installed unzipped, you can add an 
--always-unzip option to your site-wide distutils.cfg.  Then, by 
default this will unzip an egg at installation time rather than 
extracting libraries at run time.

>* 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.

That seems like a reasonable fallback, and I'll take a look at 
implementing it in a future release.  Thanks for the idea!

More information about the Distutils-SIG mailing list