On Sat, Jan 31, 2009 at 2:40 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
On Fri, Jan 30, 2009 at 12:39 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com <mailto:floris.bruynooghe@gmail.com>> wrote:
I imagine things like libdir, prefix, datadir, docdir and other
Ian Bicking wrote: 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? I don't know, and frankly the distinctions start getting really arbitrary.
They are not arbitrary - they come from standard usage and have a rationale, at least on Unix (datadir for arch independent, and libdir for arch dependent, to simplify).
I'm just about ready to run screaming from this discussion... so no, I want no part of determining what the "right" place for these files is, nor do I find it self-evident. But you mostly do not need to care, as a developer: .py files would be
considered as data files, extensions as arch-dependent, etc... The main category which needs special care is documentation, and I think I am not the only one thinking that's one thing missing in distutils ATM.
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.
I am not sure I understand how this would help OS packagers - this does not sound as the same problem at all.
Sorry, I didn't describe what I meant. I imagine some file like package-data.conf, containing: data mypackage/templates/ docs docs/_build/ At least in this example the first word is some tag, and the second is the directory, or files, or maybe a wildcard or something determining what files that tag applies to. Everything not declared but present in a package (or as a module) would default to "lib", and everything outside of that (like the setup.py file) would be "ignore". On installation, you'd write something like mypackage.egg-info/file-locations.txt, that might look like: mypackage/templates/ -> /usr/share/mypackage/templates/ docs/_build/ -> /usr/share/doc/mypackage (I'm not sure what the syntax would look like, but whatever.) Then when I did something like pkg_resources.resource_string('mypackage', 'mypackage/templates') it'd look up this file to find the location (in the absence of the file it'd act like it does currently) -- Ian Bicking | http://blog.ianbicking.org