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

Floris Bruynooghe floris.bruynooghe at gmail.com
Mon Feb 2 22:30:18 CET 2009

On Sun, Feb 01, 2009 at 03:29:52PM -0600, Ian Bicking wrote:
> I'm just about ready to run screaming from this discussion...

Thanks for not doing so

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

I really like this idea.  It seems to solve most of the issues.  For
some reason my brain kept thinking that categorising data by it's
purpose is a really natural thing to do, but that seems not so.

With this solution both packagers and developers can be happy and the
required patch to be added by a packager is really simple (add a file
with the tags).  It is even entirely possible to provide two APIs with
this system, the one you just described and one for people like me
who'd rather say get_resource('mypackage', 'datafile',


Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

More information about the Distutils-SIG mailing list