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