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

Brian Sutherland brian at vanguardistas.net
Fri Dec 10 13:42:19 CET 2010


On Fri, Dec 10, 2010 at 07:17:16AM -0500, Barry Warsaw wrote:
> On Dec 10, 2010, at 09:36 AM, Brian Sutherland wrote:
> 
> >Please don't, this has been reported various times already.
> >
> >Removing the zope/__init__.py causes breakage in other places, as I
> >detail in my response to your bug.
> >
> >I would guess that the real bug is at a deeper level.
> 
> Just a couple of things:
> 
> 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.

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.

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.

I'm hoping to be able to completely replace the custom tools we use in
python-zope.* packages with it at some point.

> 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?

What about 2nd level namespace packages (horror: zope.app.foo)?

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

-- 
Brian Sutherland


More information about the Distutils-SIG mailing list