Phillip J. Eby wrote:
At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
resources, as I said needs to be defined. You're saying here that a resource is something internal to the library. A "file" is something that a user can read, copy, or modify.
I should probably clarify that I mean "unmediated by the program"... which is why I disagree regarding message catalogs. They're not user-modifiable and there's nothing you can usefully do with them outside the program that uses them. Of course, a default message catalog for someone to use to *create* translations from might be another story...
<nod> this is what I was afraid of. This is definitely not a definition of resource-only that has meaning for Linux distributions. None of the data in /usr/share is user-modifiable (a tiny bit of it is copiable for the user to then edit the copy) and although a good fraction of it is usable outside the program that uses it, a much larger portion is taken up with things that are used by one program.
I could go through the examples below and tell why Linux distributions feel the way they do but I don't think it's necessary. Whether they're data or resources, the files need to be relocatable. And they need to be accessed via an API for that to work. So as long as we're agreed that these have to be included in the egg on some platforms and in the filesystem on others then I think we know what needs to be done.
So... do you agree on which of these are data and which are resources? Do you have an idea on how we can prevent application and framework writers from misusing the resources API to load things that are data?
Apparently not. The alternative I would suggest is that under the new standard, an install tool should be allowed to relocate any non-Python files, and all access has to go through a resource API. The install tool would then have to be responsible for putting some kind of forwarding information in the package directory to tell the resource API where it squirrelled the file(s) off to. Then we can avoid all this angels-on-a-pin argument and the distros can Have It Their Way[tm].
In terms of implementation I'd much rather see something less centered on the egg being the right way and the filesystem being a secondary concern. We should have metadata that tells us where the types of resources come from. When a package is installed on Linux the metadata could point locales at file:///usr/share/locale. When on Windows egg:locale (Perhaps the uninstalled case would use this too... that depends on how the egg structure and metadata evolves.)
A question we'd have to decide is whether this particular metadata is something that should be defined globally or per package. Or globally with a chance for packages to override it.
I'd have preferred to avoid that complexity, but if the two of us can't agree then there's no way on earth to get a community consensus.
Btw, pkg_resources' concept of "metadata" would also need to be relocatable, since e.g. the "EggTranslations" package uses that metadata to store localizations of image resources and message catalogs. (Other uses of the metadata files also inlcude scripts, dependencies, version info, etc.)
Actually, we should decide whether we want to support that kind of thing within the egg metadata at all. The other things we've been talking about belonging in the metadata are simple key value pairs. EggTranslations uses the metadata area as a data store. (Or in your definition, a resource store). This breaks with the definition of what metadata is. Translations don't store information about a package, they store alternate views of data within the package.
While the simple key value pairings can be located in either setuptools .egg-info directories or python-2.5+ distutils .egg-info files, the data store in EggTranslations can only be placed in directories.
Having a data store/resource store API would be more appropriate for the kinds of things that EggTranslation is doing.