Greg Ward wrote:
On 24 May 2000, Mark W. Alexander said:
I apologize of this is documented somewhere. If it is, I haven't found it. I've done lots of python modules, but not any packages, so if I'm just package ignorant feel free to slap me.....
It's not, and this problem is a fundamental design flaw in Python's packaging system. I have a few ideas on how we can live with it, and they generally involve "put nothing (important) in __init__.py".
Since Distutils includes a sample mxDateTime setup.py, it seemed fairly easy. I hacked it up to push it down a level (see attempt below). No problem except, of course, that it doesn't import because there's no mx.__init__.py. Ok, so I add an mx.__init__.py with __all__ defined and appropriate imports. Everything's happy and Distutils does fine.
You may be labouring under the illusion that you have to define __all__. You don't. It's just there so that you can "from package import *", where * will presumably resolve to a list of modules. (It doesn't have to, though: __init__.py can define things on its own, which then become exported by the package.)
The easiest solution is zero-byte __init__.py files. Then auto-generation is a snap, and there's no need to worry about mxDateTime clobbering the mx/__init__.py from mxTextTools (or vice-versa).
It's nice to put a brief comment or docstring in __init__.py, though -- then, it would be up to the developer (Marc-Andre in this case) to make sure the mx/__init__.py included with all of his packages is the same (or at least that all are "content-free", i.e. only comments and docstrings).
Dealing with conflicting mx/__init__.py's from multiple RPMs is another issue; I don't have a ready answer off the top o' my head. Hmmm.
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.
It looks like --bdist-WHATEVER needs information about pre- and post-installation processing. This would have to be included in setup.py somewhere.
Gee, I hope we can avoid it. But if we can't, I agree that such code 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. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/