[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-distutils-sig
Subject:    Re: [Distutils] [Python Language Summit] Distutils / Packaging
From:       Tres Seaver <tseaver () palladion ! com>
Date:       2009-01-31 20:17:43
Message-ID: 4984B1E7.6060101 () palladion ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Cournapeau wrote:
> Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ben Finney wrote:
>>   
>>> Ian Bicking <ianb@colorstudy.com> writes:
>>>
>>>     
>>>> On Fri, Jan 30, 2009 at 12:39 PM, Floris Bruynooghe <
>>>> floris.bruynooghe@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.

I don't equate "religious" with "irrational":  I mean it in the sense
that people have different assumptions ("postulate sheaths", if you like
a more mathematical approach) which are taken as "given."

For isntance, the whole idea of dividing architecure-specific bits from
architecture-independent bits is legacy (from my POV, of course) of a
day when disk space was expensive, and when sysadmins wanted / needed to
share installed software across multiple, heterogenous machines.  In
today's world, I bet that is a percent-of-a-percent minority of all
installed Unix-like boxes.

Calling .py files "data" is another choice which seems (to me)
arbitrary:  in my view, .py files, as well as others, are "software",
not data, and should be kept together with the other software (e.g.,
templates used for rendering HTML) that they are distributed with.

> Each platform has its own way of
> dealing with this, and doing against it is both futile and
> counter-productive.

I'm arguing that making it easier for platform-focused people to apply
their policies is a good thing, but is in tension with keeping the
software itself simple and supportable across multiple platforms.  For
instance, adding standardized metadata to setup.py to help packagers is
a reasonable thing to ask of Python developers.  It is a harder thing to
ask them to use an API to load support files (like the templates I
mentioned), but that can be motivated by cross-platform concerns.  On
the other hand, changing my software so that it uses some Debian- (or
BSD-, or Windows-specific) policy at runtime to load those files is
Right Out (TM).

> 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,

My original post higlighted the tension in those goals, and suggested
some of the compromises (repeated above) which packagers might
reasonably ask developers to make.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJhLHn+gerLs4ltQ4RAhduAKDQw0iJK40uR/CdoPAweMsX0cXjjQCeMQKb
nnINTY3DHvN5EWbzUTqdyPY=
=fsQ6
-----END PGP SIGNATURE-----

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[prev in list] [next in list] [prev in thread] [next in thread]