[Python-Dev] PEP 3147, __pycache__ directories and umask

[Matthias Klose]

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.
>
> +1.
>
> 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
>
>      Purpose
>
>      /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.
>
>      <URL:http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA>
>
> 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.