[Distutils] zc.buildout fails to use system-installed dep?

[Barry Warsaw]

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
file.

>It also uses standard dpkg functionality, which is a robustness bonus.

True.

>> 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[*].

[*] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python27

>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
Just Work.

>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. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20101210/39e5b682/attachment.pgp>