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 available. >* 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! _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
