Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060427/bb6f3ff6/attachment.html below:
<br><br><div><span class="gmail_quote">On 4/27/06, <b class="gmail_sendername">Phillip J. Eby</b> <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:<br>>"Gustavo Carneiro" <<a href="mailto:gjcarneiro@gmail.com">gjcarneiro@gmail.com</a>> writes:<br>><br>> > Now the problem. Suppose you have the source package python-foo-bar,
<br>> > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This<br>> > would make a module called "foo.bar" available. Likewise, you can have the<br>> > source package python-foo-zbr, which installs
<br>> $pythondir/foo/__init__.py and<br>> > $pythondir/foo/zbr.py. This would make a module called "foo.zbr"<br>> available.<br>> ><br>> > The two packages above install the file $pythondir/foo/__init__.py. If
<br>> > one of them adds some content to __init__.py, the other one will overwrite<br>> > it. Packaging these two packages for e.g. debian would be extremely<br>> > difficult, because no two .deb packages are allowed to intall the same
<br>> file.<br>> ><br>> > One solution is to generate the __init__.py file with post-install hooks<br>> > and shell scripts. Another solution would be for example to have only<br>> > python-foo-bar install the __init__.py file, but then python-foo-zbr would
<br>> > have to depend on python-foo-bar, while they're not really related.<br>><br>>Yet another solution would be to put foo/__init__.py into a third<br>>package, e.g. python-foo, on which both python-foo-bar and
<br>>python-foo-zbr depend.</blockquote><div><br> You can't be serious. One package just to install a __init__.py file?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Or you can package them with setuptools, and declare foo to be a namespace<br>package.</blockquote><div><br> Let's not assume setuptools are always used, shall we?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If installing in the mode used for building RPMs and debs, there<br>will be no __init__.py. Instead, each installs a .pth file that ensures a<br>dummy package object is created in sys.modules with an appropriate<br>__path__. This solution is packaging-system agnostic and doesn't require
<br>any special support from the packaging tool.</blockquote><div><br> 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".<br><br> 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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(The downside, however, is that neither foo.bar nor foo.zbr's __init__.py<br>will be allowed to have any content, since in some installation scenarios
<br>there will be no __init__.py at all.)</blockquote><div><br> That's ok in the context of this proposal (not having __init__.py at all). <br></div><br></div><br>
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