[Distutils] distutils data_files and setuptools.pkg_resources are driving me crazy

Bob Ippolito bob at redivi.com
Thu Jul 13 22:52:48 CEST 2006

On Jul 13, 2006, at 12:52 PM, Robin Bryce wrote:

> Hi,
> [using setuptools 0.6b4]
> Is it possible to have a separate 'zip_safe' decision for data files
> versus python packages. Ie., a deployed egg with data files and non
> zip safe packages would appear in site-packages (or wherever) as both
> a zip archive for the zip safe data AND a directory tree containing
> the 'eager' resources ?

Make separate eggs. One for the data, one for the code. The code egg  
be zip_safe and the data one not.

> I very much would prefer that the machinery for including data files
> in a package to be orthogonal to the source building/packaging
> machinery.

I highly doubt that's what most people want to bother with.

> I think there is a compelling argument that says complex data should
> be explicitly packaged separately. Ie if foopackage had non trivial
> data then I, as the package author, should create and distribute
> foopackage.egg and foopackage.data.egg as separate things.
> foopackage.egg would require foopackage.data and would, as an
> additionally benefit, be free to use existant setuptools machinery to
> separate data versions from package versions. In fact, to argue
> completely against the thrust of this mail I'm now thinking along the
> lines of:

What compelling argument?

> - *never* package data in the same egg as the application or library
> - *always* create a separate foopackage-data package, even if it has
> no python source in it beyond setup.py and even if the data is
> trivial.
> - use the optional dependencies mechanism to pull data in as needed.

That's not really convenient for most people, but if that's what you  
want to do then go ahead. Shove the data in a foopackagedata package  
which goes in a separate egg and throw a trivial __init__.py in there.


More information about the Distutils-SIG mailing list