[Distutils] installing data files and headers

M.-A. Lemburg mal@lemburg.com
Sat Mar 1 05:15:18 2003


A.M. Kuchling wrote:
> On Fri, Feb 28, 2003 at 10:31:00AM -0500, Jeremy Hylton wrote:
> 
>>Another problem we've been struggling with for Zope projects is that
>>distutils really only installs Python modules and extensions.  It's
>>support for data files and C header files is pretty limited.  We've got
> 
> 
> Good idea.  We have a similar subclass for Quixote that installs *.ptl
> files, and it's a common need.

Dito here for various documentation files, licenses etc.

The problem seems to be that all of us have slightly different
requirements here, so perhaps there simply isn't a one-fits-all
implementation.

>>installed, so that you don't install .py~ files.  One possibility is to
>>explicitly list the file extensions that constitute installable data. 
>>We did that for Zope3, but the list of extensions ended up being fairly
>>long.
> 
> Well, what are the options?
> 
> 1) List extensions.  
> 2) Explicitly list pathnames for additional files.
> 3) A MANIFEST.in-like mini-language for specifying which files should 
>    be installed.
> 4) Automatically add things in package directories that 
>    aren't obviously irrelevant (*~, *.pyc, CVS, .svn).
> 
> Any other ideas?
> 
> 4) probably offers too little control, and 3) might be too much, and
> adds yet another file to write.  What if both 1) and 2) were
> supported, say, like this:
> 
> setup(...
>       package_files=['zope/app/config.xml', 'zope/app/dtd.xml'],
>       package_patterns=['*.cfg'], 
>      )
> 
> So this adds all *.cfg files in any package directory, and the two XML
> files.  We could also allow arbitrary filenames in the 'py_modules'
> list, but then the very name 'py_modules' is misleading, so IMHO
> that's a bad idea.  
> 
> One nit is that packages are identified as 'zope.app' in the
> 'packages' and 'package_dir' keywords.  build_py will have to mess
> around with the package_files strings, but hopefully that won't be too
> difficult to get right.

Why not merge package_files and package_patterns into one
list. Then use glob.glob() to work this into a list of
single filenames.

The downside with this proposal is that you'll have to add
MANIFEST.in rules for these files as well...

>>The other problem we have is with header files.  We'd like to have .h
>>files that are installed inside a directory in /usr/local/include.  For
> 
> Why isn't installing the headers in /usr/local/python2.2/persistence
> OK?  Are these headers completely independent of Python (e.g. for a
> standalone C library)?

FWIW, I usually install the header files right along side the
package's .so files. This makes it very easy for others to
find the locations of the installed headers and avoids any
name clashes.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Mar 01 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford:                                     31 days left
EuroPython 2003, Charleroi, Belgium:                       115 days left