[Distutils] zc.buildout fails to use system-installed dep?
barry at python.org
Fri Dec 10 14:19:32 CET 2010
On Dec 10, 2010, at 01:42 PM, Brian Sutherland wrote:
>On Fri, Dec 10, 2010 at 07:17:16AM -0500, Barry Warsaw wrote:
>> The way zope.interface "owns" the zope namespace is not correct. Ideally,
>> there would be a separate binary package that owns zope/__init__.py and on
>> which all other zope subpackages depends. This could of course be built
>> from the zope.interface source package.
>I originally had it that way, but was strongly advised to change it to
>the current method to be able to pass the Debian FTP Master gauntlet.
Just goes to illustrate the myth of TOOWTDI. :) AFAICT, from my discussions
with various folks on debian-python, it should now[*] be done with the
separate binary package.
[*] At least until dh_python2, if we can ensure it always DTRT.
>The current method using dpkg-divert is not too bad, more packages than
>python-zope.interface could include that file as well. So you don't
>force installation of python-zope.interface.
Doing the diversion means it's harder for someone to explicitly determine
which package owns the file. Better (I think!) to have none of them own the
>It also uses standard dpkg functionality, which is a robustness bonus.
>> Second, we're going to make a big push after Squeeze is released to convert
>> packaging to use dh_python2, the new goodness in Debian Python packaging.
>I've had a brief look at it already and will have a much deeper look
>once squeeze is released. AFAIKR the only feature it was missing to
>completely cover my usecase was good handling of setuptools extras.
Can you be more specific? Before I got swamped with the Python 2.7 transition
(it will be the default in Ubuntu 11.04), I began looking at dh_python2,
adding unit tests, etc. I do plan to get back to it once we have the archive
more happily on Python 2.7[*].
>I'm hoping to be able to completely replace the custom tools we use in
>python-zope.* packages with it at some point.
+1. We hope to get rid of python-support and python-central.
>> This should make things more consistent, and, while I have not yet tracked
>> down specific details yet, it should make handling namespace packages much
>> more robust. For example, with my flufl packages, there is no binary
>> package owning flufl/__init__.py. That file does not show up in the binary
>> package and yet it still gets created properly when any of the subpackages
>> get installed.
>Any idea as to the mechanism?
Hints, but nothing definite. I'm not sure which part of the tool chain is
suppressing the neamespace package's __init__.py, and which part is laying it
down when the package gets installed. It *is* nice that the packager doesn't
have to worry about it though. I don't think you should have to do the tricks
zope.interface is doing, or even do the extra binary package. IOW, it should
>What about 2nd level namespace packages (horror: zope.app.foo)?
Haven't tried that yet.
>> Sadly PEP 382 was not complete in time for Python 3.2.
>Yeah, there are a lot of packaging related PEPs coming out lately. It's
>really great to see attention being paid to these dusty corners:)
Indeed! I think we all owe Tarek and the other folks an unlimited supply of
beers at the next Pycon. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Distutils-SIG