[Distutils-sig] Charter for this SIG

[Greg Ward]

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