[Distutils] Pondering multi-package packages

[M.-A. Lemburg]

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/