On 23.03.2010 02:28, Ben Finney wrote:
Antoine Pitrou<solip...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
