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