[Python-Dev] PEP 3147, __pycache__ directories and umask
ben+python at benfinney.id.au
Tue Mar 23 02:28:36 CET 2010
Antoine Pitrou <solipsis at pitrou.net> writes:
> Barry Warsaw <barry <at> python.org> writes:
> > When Python is being installed, either by a from-source 'make
> > install' or by the distro packager, then you'd expect the umask not
> > to be insane. In the latter case, it's a bug and in the former case
> > you screwed up so you should be able to delete and reinstall, or at
> > the very least execute the same `find` command that Python's own
> > Makefile calls (in my branch) for 'make clean'.
> > When you're installing packages, again, I would expect that the
> > system installer, or you via `easy_install` or whatever, would not
> > have an insane umask.
> Well, precisely. That's why I suggest that creating the __pycache__
> directories be done *at install time* (or packaging time), and not via
> the core import machinery (that is, not at import time). That is, when
> you *know* you are the right user, with the right umask.
Taking advantage of caching directories that have already been set up
correctly in advance at install time is friendly. Littering the runtime
directory with new subdirectories by default is not so friendly.
Perhaps also of note is that the FHS recommends systems use
‘/var/cache/foo/’ for cached data from applications:
/var/cache : Application cache data
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or calculation. The
application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss. The data
must remain valid between invocations of the application and rebooting
This would suggest that Python could start using ‘/var/cache/python/’
for its cached bytecode tree on systems that implement the FHS.
\ “Simplicity and elegance are unpopular because they require |
`\ hard work and discipline to achieve and education to be |
_o__) appreciated.” —Edsger W. Dijkstra |
More information about the Python-Dev