[Distutils] Pondering multi-package packages

[Mark W. Alexander]

On Thu, 25 May 2000, M.-A. Lemburg wrote:
> 
> FYI, I'm going to package the mx stuff in 3-4 ZIP archives:
> 
> 1. base (this one contains the __init__.py file and always
>    has to be installed)
> 2. crypto (optional add-in with mx.Crypto)
> 3. mx-ug (subpackages only available to mx User Group members)
> 4. commercial (things like mx.ODBC and some other DB related
>    subpackages)
> 
> There will no longer be separate mxTools, mxTextTools,
> mxDateTime, etc. packages.

I think that pretty much resolves the issue with mx.Stuff. It
still remains a generic problem for other packages though. Do
you have an ETA on your new packages? If not, shoot me an
email and I'll be happy to do the setup.py scripts.

> 
> > should be provided as Python; it's up to the Distutils to cook up a way
> > to run that code at installation-time.  Yuck!  Hairy, hairy, hairy...
> 
> Umm, what's hairy about pre- and post-install code ? Pretty
> much all RPM-like archives provide this feature in some way
> or another. 
> 
> I'd suggest to have setup.py include a reference
> to two functions somewhere (probably in the setup constructor):
> one to run for pre-install and one for post-install.

I also think this is a definite long-term need. For "relocatable"
python packages on some architectures (e.g. Solaris) it may be
necessary to re-link at install time (ld -rpath) to avoid 
requiring the user to set LD_LIBRARY_PATH. (IANALG -- I Am 
Not A Linking Guru, but I've had problems when things libraries
ar in different places on "install" machines than they are on 
"build" machines.

That said, it's probably only an issue when you're stuck with
bunches fo boxes with different file system setups where your
forced to put things where you can find the room. That
probably means me and some other guy whose still lost
writing perl ;-) If no one else is interested, I'll do it
when hell freezes^W^W I have time.

mwa