[Distutils] Pondering multi-package packages

[Mark W. Alexander]

On Fri, 26 May 2000, M.-A. Lemburg wrote:
> 
> Well, e.g. mxDateTime was a package in the sense that you can
> unzip it directly in a directory on you PYTHONPATH. Only the
> "base" archive will have that property. The others are
> add-in archives which get unzipped on top of the "base"
> installation.
> 
> Hmm, thinking of it: would distutils allow recursive
> builds/installs ? Or must I add logic to figure out
> which parts of the cake are available to build/install and
> then setup a single setup.py file ?

It allows for nested packages, if that's what you mean. I 
didn't have much trouble backing a setup.py that did
mxDateTime, mxTextTools, and mxTools. I don't see any
problem with each having their own setup.py, IF you have
(as you mentioned) a "core" package that provides the 
foundation for all the others.

Earlier, someon else said:

> > BTW, how can I add some Q&A style setup dialog to build and
> > install commands ?

This is another good question. The SysV 'pkgtool' utilities
allow not only preinstall and postinstall, but preremove,
postremove and request scripts. The request script is invoked
before anything is done, and allows Q&A with the installer
to support customized installation.

Having to support multiple packages on multiple machines of
multiple architectures, I'm a strong believer in the idea
that the installer should have complete controll over package
installation, IF they want it (appropriate defaults assumed).
In order to provide that level of flexibility, the requirements
for the bdist-* modules are pushed to the point of having to
provide the maximum requirements of the most complex
package manager supported. This is likely to get very ugly.

Pardon me while I talk circles around myself......

I'm starting to go back to what someone (Henry?) said early
in the bdist-rpm progress, provide the package specification
file and let it go at that. Where possible, take it to the
max like bdist-rpm is, but as a minimal bdist requirement
the only function required (and possibly default?) could be
that of  --spec-only.

I really like where distutils is headed (actually, where it's
at is pretty darn good!), and I hate to see much effort go 
into the 20% of functions that hardly anyone would use.
"Most" packages don't need any scripts. Those that have
major scripting needs are probably best addressed by 
a packager who understands packaging fairly thoroughly.
Getting a spec/prototype/pkginfo/psf file, can be tedious
and is the one thing distutils can easily provide. The
packager can plug scripts in as required.

Mark Alexander
mwa@gate.net