launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Jonathan Lange wrote:
> Hello,
> 
> Skip the next paragraph if you want to go straight to helping me and
> don't care about context.
> 
> Now that we are using a recent zope.testing, I want to ditch some of
> the ugly hacks that I added to our test script by making them genuine,
> tested features in zope.testing itself. I've started this work, and
> zope.testing 3.9.0 has full support for subunit output.
> 
> 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.

Can you simply switch to using it from packages?
$ rmadison python-subunit
python-subunit |    0.0.2-1 | karmic/universe | all
python-subunit |    0.0.5-1 | lucid/universe | all

Hardy packages are being built by the LOSA's in their archive for bzr's
hardy testing environment, if hardy is needed. I can supply the diff gz
to build that for EC2 or whatever easily.

And there is a PPA (the subunit release PPA) with current released
subunit built for all supported Ubuntus.

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

I'd be happy to have a mechanism to build an egg in the autotools python
support; subunit itself isn't a python project per se: its a C library
and a python library and a shell library ... etc. I don't particularly
like mixing build systems in one project - I may be convinced to add a
setup.py, but I'd like to investigate other options first.

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

Makes sense to me.

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

That might be useful for the LOSA's anyway.

> 2a. How would I find that out without asking the list?
> 
> 2b. How many times do we have to write branch mirroring code anyway?
> 
> 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.

I don't know what would be needed for buildout.

Nevertheless, I'd really consider just using packages: subunit is not a
particularly fast moving target; there is a PPA with current release if
you need the latest released code.

-Rob