[Distutils] [Python Language Summit] Distutils / Packaging survey

[David Cournapeau]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ben Finney wrote:
>   
>> Ian Bicking <ianb at colorstudy.com> writes:
>>
>>     
>>> On Fri, Jan 30, 2009 at 12:39 PM, Floris Bruynooghe <
>>> floris.bruynooghe at gmail.com> wrote:
>>>
>>>       
>>>> I imagine things like libdir, prefix, datadir, docdir and other
>>>> things copied from autoconf. Where the defaults would be something
>>>> like:
>>>>
>>>> prefix = sys.prefix
>>>> libdir = sys.prefix/lib/pythonX.Y/site-packages/pkgname
>>>> datadir = sys.prefix/share/mypackage
>>>> docdir = sys.prefix/share/doc/mypackage
>>>>         
>>> I wouldn't want to use those. What goes in libdir, what goes in
>>> datadir?
>>>       
>> Again, I expect Floris is using these terms in their traditional
>> meanings.
>>
>> “library” would be a collection of executable code intended for use
>> as a unit; what Pythoncalls a “package” (or the degerate case of a
>> “module”).
>>
>> “data” would be non-executable files used by the package that don't
>> fit any other (e.g. “documentation”) classification.
>>
>>     
>>> I don't know, and frankly the distinctions start getting really
>>> arbitrary.
>>>       
>> Hopefully that clarifies.
>>
>>     
>>> I would rather see something like pkg_resources existing API, where
>>> there is some file that maps out how the local names of files (where
>>> they'd be in a checkout) map to their installed location, then the
>>> pkg_resources code could finds the real location of the file.
>>>       
>> This loses the indirection that is so sorely needed of tagging
>> resources by *type*, so that their install location can be decided on
>> that basis.
>>
>> Deciding on a file-by-file basis where files get installed is
>> something that distributors and packagers already have to do, and it's
>> a massive pain.
>>
>> Allowing the developer to tag resources by type is a sensible division
>> of responsibility: the developer knows the *purpose* (and therefore
>> type) of the resource, and the packager knows the appropriate
>> *location* on the filesystem for resources of a particular type.
>>     
>
> The need for those distinctions derives from a particular distributor's
> / packager's "religion":  e.g., the insistance that "template" files
> (software, but not "executable" by some criterion) mut not be kept in
> the same directory with the other software.  That rule is important for
> some packagers, and completely mystifying / irrelevant to the original
> develpoers or to packagers with a different model.
>   

That's not a religion: it has rationales. You may not agree with them,
both those splits are not arbitrary. Each platform has its own way of
dealing with this, and doing against it is both futile and
counter-productive.

Of course some of the distributions aspects are irrelevant to you - but
so are some of your interests to packagers. At the risk of sounding
obvious: developers and packagers do not have the same goals, and they
sometimes conflict. But you cannot expect "not to care" and "my software
will be available everywhere" at the same time. That's why those
discussion are tiresome and difficult: there has to be some compromise.
There is not right solution,

David