On Mar 15, 2010, at 9:23 AM, Jonathan Lange wrote: > On Sun, Mar 14, 2010 at 9:45 PM, Michael Hudson > <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
