Ian Bicking <i...@colorstudy.com> writes: > On Fri, Jan 30, 2009 at 12:39 PM, Floris Bruynooghe < > floris.bruynoo...@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. -- \ “If life deals you lemons, why not go kill someone with the | `\ lemons (maybe by shoving them down his throat).” —Jack Handey | _o__) | Ben Finney _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
