[Distutils] Proposal: Meta extensions (components)

[Paul Prescod]

Andrew Kuchling wrote:
> 
> On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote:
> >I could have a special case for NumPy and a special case for ZODB and a
> >special case for ... But there are around 600 extensions on the Vaults
> >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to
> 
> The unified ZODB distribution is really several extensions in one:
> ExtensionClasses, for example, are potentially useful in their own
> right without the rest of ZODB.  

I've been thinking about this today. I'd like feedback on a proposal.

Let's start with terminology: there is a "missing term" in our
vocabulary. People sometimes use the words "module", "extension" and
"package" for a "distutils unit" but those words already have precise
meanings in the Python world. I propose the term "distutils component".
A distutils component consists of a directory which contains a setup.py
and some other code. The component is also the unit of versioning.

Some components "embed" other components. The parent component is
dependent on the embedded component and for convenience, the embedded
component is distributed with the parent. Embedding may go away when
distutils has proper dependency tracking -- but it may not.

It should be possible to create a "parent component" or "meta component"
by specifying the paths to sub-components. Just as you specify
"py_modules", "extensions" and so forth, you should be able to specify
"sub_components". Then distutils itself would do all of the "for
subcomponent in subcomponents: run_setup()" hackery that NumPy, ZODB,
etc. do "by hand" today.

This could map into installers too. There is probably a way to create
RPMs that contain RPMs, windows EXEs that contain windows EXEs and so
forth.

 Paul Prescod