At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:
>"Gustavo Carneiro" <gjcarneiro@gmail.com> writes:
>
> >   Now the problem.  Suppose you have the source package python-foo-bar,
> > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py.  This
> > would make a module called "foo.bar" available.  Likewise, you can have the
> > source package python-foo-zbr, which installs
> $pythondir/foo/__init__.py and
> > $pythondir/foo/zbr.py.  This would make a module called "foo.zbr"
> available.
> >
> >   The two packages above install the file $pythondir/foo/__init__.py.  If
> > one of them adds some content to __init__.py, the other one will overwrite
> > it.  Packaging these two packages for e.g. debian would be extremely
> > difficult, because no two .deb packages are allowed to intall the same
> file.
> >
> >   One solution is to generate the __init__.py file with post-install hooks
> > and shell scripts.  Another solution would be for example to have only
> > python-foo-bar install the __init__.py file, but then python-foo-zbr would
> > have to depend on python-foo-bar, while they're not really related.
>
>Yet another solution would be to put foo/__init__.py into a third
>package, e.g. python-foo, on which both python-foo-bar and
>python-foo-zbr depend.

Or you can package them with setuptools, and declare foo to be a namespace
package.

  If installing in the mode used for building RPMs and debs, there
will be no __init__.py.  Instead, each installs a .pth file that ensures a
dummy package object is created in sys.modules with an appropriate
__path__.  This solution is packaging-system agnostic and doesn't require
any special support from the packaging tool.

(The downside, however, is that neither foo.bar nor foo.zbr's __init__.py
will be allowed to have any content, since in some installation scenarios
there will be no __init__.py at all.)