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