[Python-Dev] Dropping init.py requirement for subpackages (original) (raw)

Phillip J. Eby pje at telecommunity.com
Thu Apr 27 16:50:39 CEST 2006

At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:

"Gustavo Carneiro" <gjcarneiro at gmail.com> writes:

> Now the problem. Suppose you have the source package python-foo-bar, > which installs pythondir/foo/init.pyandpythondir/foo/init.py and pythondir/foo/i​nit.​pyandpythondir/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.)

More information about the Python-Dev mailing list