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

[Tres Seaver]

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

Right now, making the 'pkg_resources' jump can be motivated by
cross-platform concerns, e.g. a desire to allow the "package_data" files
to be loaded from a zipfile / egg.  Anything more complicated at
*runtime* (as opposed to metadata added to the 'sdist') is harder to
motivate.

The "uptake" problem here is both to motivate the non-believer to help
with the distinctions, and to make the burden of doing so as minimal as
possible.  This discussion has broken down before at exactly this point,
IIRC.

As a packaging-agnostic developer, I'm +0 on the idea of making it
easier to package my software:

- - I do appreciate having folks able to install the software easily;

- - However, complexifying the software itself to make some packagers
  happy is a burden, and a potential source of bugs;

- - Sometimes, packagesrs *break* my software in ways I can't support.

If we can drive the first concern down, I can live better with the
second (and perhaps it will become less likely).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at 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

iD8DBQFJhBMY+gerLs4ltQ4RAl5CAKCHP1Y3ja65uQZGRowdu8C+R2lcJwCgmNbV
JjXgoibfZumIRJjYmlsr9XE=
=//L/
-----END PGP SIGNATURE-----