[Distutils] "Python Package Management Sucks"

[Toshio Kuratomi]

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.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081001/26e7ebbd/attachment-0001.pgp>