distutils-sig: forum to discuss module distribution utilities for Python 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 The starting point for discussion on the sig will be the summary of the IPC7 Developer's Day session which got this whole thing rolling: http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html