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