[Distutils] Pondering multi-package packages
M.-A. Lemburg
mal@lemburg.com
Thu, 25 May 2000 17:52:44 +0200
"Mark W. Alexander" wrote:
>
> 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.
This depends on whether I'll find time within the next
month to get the docs right and setup the web site for
the new tools.
> > > 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.
Right, but there are other more serious needs as well,
e.g. a package might want to prebuild some database or
scan the system to figure out configuration information,
initialize third party tools, register APIs, COM or CORBA
objects, check package dependencies etc. (just look at what
CPAN does when you let it do its thing in automatic mode).
There are many possibilities which can't possibly all be
covered by special install or build functions.
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/