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