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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4