[Python-Dev] Dropping __init__.py requirement for subpackages
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
> > > 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
> > > 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
> > > 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
> > > 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
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...
More information about the Python-Dev