=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[21:19] <balloons> veebers! hello my friend
[21:20] <balloons> I am one curious cat on when we might see an new autopilot release. And specifically, I want https://code.launchpad.net/~nskaggs/autopilot/add-wm-sandbox-run/+merge/242274 in it :-)
[21:21] <veebers> balloons:hey o/
[21:23] <veebers> balloons: I could probably do one soon as I have a fix for unit test failures on wily. that would bring it in check with the vivid overlay (with the pointer fix)
[21:26] <balloons> right.. that's also weird to have vivid overlay be > wily
[21:26] <balloons> but then, the overlay is a different story :-)
[21:28] <veebers> heh yeah, helps to make things a little more complicated. I'm not even sure if I can land in vivid overlay right now
[21:40] <balloons> ok. And the release ofc would still be Autopilot 1.5 yes? I take it 1.6 is being held up with all these quick fixes going in?
[21:46] <veebers> balloons: aye, would still be 1.5
[21:47] <veebers> balloons: d'oh, I thought I had top approved this ages ago, was a little confused why it might not have been released
[21:47] <veebers> balloons: let me top approve now and get a release in action
[21:47] <veebers> is a good opportunity to sync wily/vivid
[21:49] <balloons> veebers, that would be excellent. The new plugin for the SDK really needs to functionality
[21:50] <veebers> balloons: I'm not sure I follow that?
[21:50] <balloons> lol.. my typing / long day
[21:51] <balloons> in short, I need to use a WM with the sandbox script, but can't until this is released
[21:51] <balloons> and I too had thought it had gone in
[21:53] <veebers> balloons: ah I see. Yeah sorry about that, hiccup on my part. Once merged to trunk I'll do the mojo needed to try get a branch that will land in v/w
[21:54] <veebers> or failing that just do 2 releases
[21:54]  * balloons pictures veebers whispering incantations
[22:01] <veebers> ^_^
[22:08] <ahayzen> Hi, is there a way of telling autopilot to launch the app as if it was going to run the tests (eg run setUp() etc), but not actually run them so i can test/debug the mocking/fixtures ?
[22:10] <veebers> ahayzen: launching the app is separate to the tests or fixtures. You can always use a debugger and set a breakpoint where you want to start digging.
[22:10] <veebers> i.e. import pdb; pdb.set_trace()
[22:10] <veebers> although I like using ipdb instead as its a little nicer
[22:11] <ahayzen> but i want to test why the fixtures/mocking aren't working, so i just want to 'run' the tests...without actually running the tests
[22:15] <veebers> ahayzen: well, you could always write a standalone script and test the fixtures that way, but if you're wanting to debug a test you're going to have to run the test
[22:15] <ahayzen> ok :-) i guess i could just have an empty test thinking about it