[Python-Dev] PEP 3147, __pycache__ directories and umask
doko at ubuntu.com
Tue Mar 23 05:55:03 CET 2010
On 23.03.2010 02:28, Ben Finney wrote:
> 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
> the system.
> This would suggest that Python could start using ‘/var/cache/python/’
> for its cached bytecode tree on systems that implement the FHS.
it reads *data*, not code.
More information about the Python-Dev