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