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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
