Robert Kern wrote: ....... > > They're a cache. they're actually the files that get used by the installed extension in this case (MySQLdb).
.......... >> >> it would seem simpler to have the .so files inside the site-packages and >> there's >> the question of why this folder has to be obfuscated (name starts with .). >> Even >> if these files are "resources" why should they be assumed to belong to the >> user? > > Because they are unpacked at runtime by the user that imported the module. > Usually, they won't have write access to site-packages. > in this particular case the python being used was installed with a user prefix eg /myhome/PYTHON so everything belongs to the user; extensions installed by the same user can surely be installed in those folders. Upon checking I find that the same installs which produced the ~/.python-eggs files also managed to put the eggs like MySQL_python-1.2.2-py2.3-freebsd-6.1-SECURITY-i386.egg inside the various site-packages directories. I see no reason why the binary resources shouldn't be unpacked to site-packages at install time. It seems reasonable that since install time is the only time an egg install can reasonably expect to write to the install area then that's when these resources should be unpacked. The zipapp install system referred to by John Lee does it that way because in practice we find we do need to install on CD's etc. What happens if I as a naive idiot install an egg to a write once file system? I suppose the assumption is that we don't mind such files being created in the user's space. Spewing stuff all over some else's disk at run time instead of doing it once at install is wrong and may not even be possible. It also allows for the carefully crafted binary extensions to be substituted by anyone with write permission to the cache folder. -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list