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
signature.asc
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
