Python Distutils-SIG

Charter

The Distutils-SIG exists to discuss the design and implementation of a suite of module distribution utilities for Python. These utilities will take the form of some standard modules, probably grouped in the 'distutils' package, for building, packaging, and installing third-party modules. This includes both modules written purely in Python and extension modules written in C/C++.

The main deliverable will be the following core modules (in the distutils package):

• build:provides code for building a module, which might include copying .py files into a staging area, compiling and linking .c files, processing documentation to an installable form, etc.
• dist: create a source distribution
• bdist: create a 'built distribution' (the equivalent of a 'binary distribution', except that binaries won't necessarily be present
• install: install a built library on the local machine
• gen_make: generate a Makefile to do some of the above tasks (mainly 'build', for developer convenience and efficiency)

I will tentatively put forward March 1999 as a target for a working release to run on top of Python 1.5.2, which might require a patch-and-rebuild-Python step (or might find ways to work with the information available under 1.5). For a complete, tested, documented suite ready to bundle with Python 1.6, let's shoot for June 1999.

Other topics of interest:

• encouraging module developers to write test suites by having a standard place for them in module distributions
• ditto for documentation -- although this is probably the job of the doc-sig, it would be nice to tie the two together at some point
• a standard for representing and comparing version numbers
• social engineering in general, ie. convincing module developers to start using the system
• the possible need for tweaks to the configure/build process for Python itself, and a place to hold configuration information (possibly a new built-in module, 'sys.config')
• possibly rewriting the configure/build/install process for Python 1.6 -- especially useful if the distutils are bundled with 1.6!
• ties to Trove -- any module distribution scheme must include a way to describe the package metadata, and there will need to be hooks between any future Trove archive for Python and this metadata
• recognizing SWIG-assisted extensions in addition to "ordinary" C extensions