[19:41] morning [21:55] cjwatson: Hum, why did you choose to include the virtualenv in the tarball? [21:56] That seems pretty dodgy. [22:01] they aren't typically portable... [22:05] I thought the deployment target would be similar enough to the build environment in this very specific case that that wouldn't be a problem [22:06] so the two specific things that cause issues [22:07] a) the path is hard coded [22:07] cjwatson: What about eg. libgit2 versions? [22:07] Does the mojo build container have the right one? [22:07] Or paths. [22:07] We can make it have the right one! [22:07] b) so library bumps can cause havoc (e.g. even with Python x.y rebuilds) [22:07] But maybe paths are an issue. [22:07] Absolute paths are hardcoded in virtualenvs for no obvious reason. [22:07] we broke virtualenvs in 2.7 on some ubuntu releases with that one [22:08] Eh, Python minor releases always break a lot of things. [22:08] I also wanted to avoid having the virtualenv construction code be duplicated. But perhaps we could ship an appropriate script in the tarball and use it in turnip's Makefile. [22:08] SRUing them is entirely insane, so not a huge issue. [22:08] (Or ship the Makefile, which we probably already do.) [22:08] cjwatson: so, I'd suggest an LXC container if you want a big blob to ship around [22:09] cjwatson: (or similar) [22:09] Er [22:09] I don't think you're entirely familiar with the environment here [22:09] cjwatson: otherwise construct in-place is much better for virtualenvs [22:09] cjwatson: I'm surely stale :) [22:09] cjwatson: happy to be educated, or to butt out :) [22:10] I think nesting an LXC container (at least in some cases it will be nesting) is probably overkill. This is in the context of a Mojo deployment [22:10] But I'm happy to convert to constructing in-place - I didn't realise virtualenvs were quite *that* fragile [22:10] They're entirely unportable for a combination of good and terrible reasons. [22:11] (Well, convert back, but with better code for it.) [22:11] The long-term solution is to use wheels. [22:11] Having a separate virtualenv build script probably makes sense. [22:11] lifeless: more specifically the context is lp:~cjwatson/turnip/virtualenv [22:11] That gets us closer to using wheels - I just didn't do that as a first step [22:12] It wouldn't take much to have a "make compile" equivalent on top of that branch. [22:14] lifeless: (sorry, the above came across sharper than intended, I was just having an "argh, not another container" moment) [22:21] cjwatson: no worries [22:22] cjwatson: I've merged your testtools branch now (sorry for the delay) - and filed the bug on twisted [22:22] cjwatson: I'll cut a release after the tokyo summit I think, unless you're blocked ? [22:25] lifeless: I saw, thanks! Not blocked at the moment, because I need to yak-shave extensively before we can upgrade testtools [22:26] (i.e. convert Launchpad to pip) [22:27] And I think I want to build up experience with something a bit smaller like turnip before finishing off my embryonic work on that [22:41] cjwatson: well, not quite as terrifying as juju-fying lp. That's going to be interesting. [22:41] blr: Yes, quite. Though working on this I begin to see some of the shape that that could take. [22:41] right [22:42] Once we're on pip I think I could reasonably figure out how to jujuify importds, err, given about two or three weeks