[Distutils] "Python Package Management Sucks"

[Phillip J. Eby]

At 01:20 PM 10/2/2008 +0200, Josselin Mouette wrote:
>Le mercredi 01 octobre 2008 à 19:59 -0400, Phillip J. Eby a écrit :
> > >locale/{message catalogs for various languages} --  These are binary
> > >files that contain strings that the user may see when a message is
> > >given.  These, I think are data.
> >
> > I lean the other way, since they're not editable.
>
>Locale data should be shipped in standard form, in /usr/share/locale.
>Again, Python is not the only thing you need to think of. Not only, if
>you don’t use standard gettext catalogs, you are breaking translation
>tools, but if you don’t ship them at the standard location, you are
>breaking tools like localepurge (or anything that cleans up the
>filesystem based on standard file locations).
>
> > Keep in mind that
> > some platforms have no "locale" directories as such, and thus trying
> > to support multiple locations thereof is a burden for cross-platform
> > app developers, vs. simply treating them as internal resources.
>
>No, you are making the burden heavier for Linux platforms by trying to
>be more portable. There is no reason why you can’t define a locale
>directory on platforms where it does not exist, but when it exists a
>standards document defining where files go, you must follow it. Any time
>you don’t follow it, we consider it a serious breakage and we have to
>patch the code anyway.

We are defining an *extensible* standard by which developers and 
build tools will be able to tell what files in a Python project's 
distribution directories are what "kind" of files and how they should 
be handled on a given platform, and a way for installation tools to 
let the installed project access any files that the tool relocates.

That means that:

1. An FHS-friendly installation tool will be able to put data files 
with .mo/.po extensions wherever it pleases, and

2. An optional "locale info" metadata namespace could be defined by 
and for such tools, to allow more precise specification regarding 
these files, if they can't be identified automatically.  (Similar to 
how there will need to be optional metadata namespaces for things 
like icons and menus for Windows, Mac, and other desktops.)

Is this "making the burden heavier for linux platforms"?  Well, it is 
for creating the installation tool, I suppose.  And if you can't 
detect what needs to be done automatically, you'll have to encourage 
upstream add the information to their specs.

However, that will be true whether the information is "optional" or 
"required".  And non-linux platforms will certainly have their own 
extensions to deal with as well (e.g. registry on Windows, "system" 
DLLs, exe manifests, etc.).  So I think it's reasonable to put 
platform-specific burdens on the installation tools for those 
platforms - the whole point being to not have *one* installation tool 
team that's got to mentally juggle all platforms' 
requirements.  Defining the *spec* is going to be tough enough as it is.


>Sorry, but things don’t work this way. Anything that is *not* a .py file
>should not land in the python module directories. This is utter abuse of
>a loophole of the implementation, and I can’t think of another language
>that allows that. You will not find anything else than perl modules in
>the perl modules directories. You will not find anything else than C#
>modules in the Mono modules directory. And so on.

I don't see how this is remotely relevant to how Python works or how 
people use (and have used) Python over the decades.  Data files in 
package directories is something I've seen in Python since, oh, 1997 
or so.  If it were a mistake for Python, I think somebody would've 
noticed by now.

In any case, "should" is irrelevant; these packages exist in the 
field and if the only reason not to have them is to not annoy Linux 
packagers, there's not much that can be done about it.  I could even 
agree with you, and it would still make no difference: you'd have to 
get basically *everyone* to agree with you, and it's just not gonna happen.


> > 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].
>
>I don’t understand why you want to make it so complicated. All you need
>is a way to specify directories where different kinds of files land and
>a simple API to retrieve the file names/contents. Then, you can ship the
>files at the place you like in eggs, and we can ship the files at the
>standard places in our packages.

How is that not *exactly* what I said in the paragraph above 
yours?  All I added was that "some kind of forwarding information" be 
used to implement the "simple API to retrieve the file names/contents".

In the case of Linux, of course, symlinks would be an ideal "kind of 
forwarding information" (at least from a Python developer POV), since 
it would allow most existing programs to work with no changes -- even 
ones that don't use the pkg_resources API.