launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Mar 15, 2010, at 9:23 AM, Jonathan Lange wrote:

> On Sun, Mar 14, 2010 at 9:45 PM, Michael Hudson
> <michael.hudson@xxxxxxxxxxxxx> wrote:
>> Jonathan Lange wrote:
>>> Hello,
>>> 
> ...
>>> 
>>> I'd like to upgrade zope.testing and take advantage of their better
>>> subunit support, but that requires upgrading subunit too.
>>> 
>>> We currently maintain subunit as a sourcecode dependency. We manage it
>>> in the branch lp:~launchpad-pqm/subunit/trunk. That branch is a
>>> KnitPackRepository. subunit trunk is a 2a repository.
>>> 
>>> If I naively change sourcedeps.conf like so:
>>> @@ -12,7 +12,7 @@
>>> -subunit lp:~launchpad-pqm/subunit/trunk;revno=61
>>> +subunit lp:~subunit/subunit/trunk;revno=120
>>> 
>>> I get incompatible repository errors.
>>> 
>>> subunit is not a Python package. It's built with autotools, and thus
>>> making an egg for it is beyond my ken and maybe inappropriate.
>>> 
>>> Which leaves me with a bunch of questions:
>>> 
>>> 1. Changing sourcedeps.conf to point to a branch that's not managed by
>>> our PQM is OK, isn't it? After all, we still have to pass the tests to
>>> change the revno of the branch, so we aren't losing any safety afaict.
>> 
>> As Max said, we are losing some safety.  Not sure how much or how much
>> we care.
>> 
> 
> I think we don't care.
> 
>>> 2. If I changed update-sourcecode to just do a full remirror if the
>>> repository formats are incompatible, would we then encounter problems
>>> when we rolled out to production?
>> 
>> Not sure.
>> 
>>> 2a. How would I find that out without asking the list?
>> 
>> Reading
>> https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout
>> might provide some clues (I haven't read all of it, tbh)
>> 
> 
> Eek!
> 
>>> 3. Should we instead use buildout?
>>> 
>>> 3a. If so, how on earth do I package subunit so that it can be used
>>> with buildout? Bear in mind this is something I doing in my personal
>>> time, so if it's not easy or the fun kind of hard, I'm not going to do
>>> it.
>> 
>> Given the nature of subunit, I think Rob's suggestion of using a deb for
>> it makes some sense.  Although the lack of hardy packages is obviously a
>> blocker.
>> 
> 
> Thanks to you, Rob & Max for the help. Sadly, I think I'm still blocked.
> 
> I think subunit is relatively fast-moving compared to our other
> dependencies, and I don't think that .deb packaging is the best way to
> deal with that. In general, I don't really understand why one package
> should be maintained in buildout and another as an Ubuntu dependency.
> 
> Further, I don't actually know how to switch it to use Ubuntu
> packages, and am just as unclear on what impact that would have on the
> buildslaves & prod environments as I am about changing
> update-sourcecode.py.

If you want to pursue buildout for adding this dependency, there are two routes.

- subunit gets a setup.py.  If avoiding setuptools is a goal, this could maybe be a distutils-only version that produced an sdist.  setuptools might be easier in the long run though.

- http://pypi.python.org/pypi/zc.recipe.cmmi supports configure-make-make install ("cmmi") packages.  Looks like the autogen option could be used to bootstrap subunit (autoreconf -vi).  This would probably be the easiest to do, especially if you could somehow make me do it. :-P

Gary