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

Gustavo Carneiro gjcarneiro at gmail.com
Thu Apr 27 17:14:58 CEST 2006

On 4/27/06, Phillip J. Eby <pje at telecommunity.com> wrote:

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.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.

You can't be serious. One package just to install a init.py file?

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

package.

Let's not assume setuptools are always used, shall we?

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.

I don't understand this solution. How can a .pth file create a 'dummy package'? Remember that the objective is to have "foo.bar" and "foo.zbr" modules, not just "bar" and "zbr".

But in any case, it already sounds like a convoluted solution. No way it can beat the obvious/simple solution: to remove the need to have init.py in the first place.

(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.)

That's ok in the context of this proposal (not having init.py at all). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060427/bb6f3ff6/attachment.html

More information about the Python-Dev mailing list