At 11:00 AM 10/1/2008 -0700, Toshio Kuratomi wrote:
I have no love for how pkg_resources implements this (including the API) but the idea of retrieving data files, locales, config files, etc from an API is good. For packages to be coded that conform to the File Hierachy Standard on Linux, the API (and metadata) needs to be more flexible.
There's some confusion here. pkg_resources implements *resource* management and *metadata* management... NOT "file management".
Resource files and metadata are no more "data" in the FHS sense than static data segments in a .so file are; they are simply a more convenient way of including such data than having a giant base64 string or something like that hardcoded into the program itself. There is thus no relevance to the FHS and absolutely no reason for them to live anywhere except within the Python packages they are a part of.
We need to be able to mark locale, config, and data files in the metadata.
Sure... and having a standard for specifying that kind of application/system-level install stuff is great; it's just entirely outside the scope of what eggs are for.
To be clear, I mean here that a "file" (as opposed to a resource) is something that the user is expected to be able to read or copy, or modify. (Whereas a resource is something that is entirely internal to a library, and metadata is information *about* the library itself.)
The build/install tool needs to be able to install those into the filesystem in the proper places for a Linux distro, an egg, etc. and then we need to be able to call an API to retrieve the specific class of resources or a directory associated with them.
Agreed... assuming of course that we're keeping a clear distinction between static resources+metadata and actual "data" (e.g. configuration) files.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
