[Python-Dev] Dropping __init__.py requirement for subpackages

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