[02:37] wgrant: the lack of that feature unfortunately means the diff api test is less than ideal. not entirely sure what to do about that [02:53] wgrant: here if you have a moment to look https://code.launchpad.net/~blr/turnip/api-diff [04:01] blr: The lack of which feature? [04:01] patch parsing [04:01] sorry split-channel context :P [04:01] Oh, #ci, right. [04:01] Just catching up. [04:03] wgrant: test is a bit braindead (test_repo_compare_commits() in http://bazaar.launchpad.net/~blr/turnip/api-diff/revision/96 test_api.py) without patch parsing [04:04] on a related note, have since moved some of that pygit2 ugliness to test_helpers property in a later revision. [04:07] blr: We can write some better tests if we construct a known tree and check for relevant +/- lines etc. [04:07] wgrant: right, that would be better, but will still need to regex the json body. [04:09] wgrant: just trying to think about how to achieve that within the context of http://bazaar.launchpad.net/~blr/turnip/api-diff/view/head:/turnip/api/tests/test_helpers.py [04:10] wgrant: afaict, I can't _apply_ a patch with pygit2 either. [04:11] blr: I don't believe there's a way to do that today, no. [04:11] Fortunately we don't need to right now :) [04:13] blr: It probably makes sense to have a test helper that constructs a tree given a dict of {path: content}, allowing us to easily create commits that look as we desire. [04:13] That would make the diff test quite simple. [04:13] that makes sense... is what is there currently reasonably sane? [04:16] blr: Looks generally sensible to me! [04:16] wgrant: great, thanks [06:25] blr: Any idea why the turnipcake charm doesn't seem to expose any ports? I can see them defined in the service config, just like in turnip, but juju status doesn't show them. [06:30] Oh, it would help if I added the relation so the services framework actually started it, wouldn't it. [06:48] wgrant: test helpers for file trees - bzr has one already [06:49] wgrant: if you can't reuse that, you could add one to fixtures easily enough, I'd be happy to accept a patch extending the existing stuff [06:49] lifeless: "tree" as in the git object, not an actual tree. [06:49] wgrant: sure; probably one of those in jelmers git protocol impl :) [06:51] Indeed. === Peng_ is now known as Peng [08:01] cjwatson: Hrm, did you run the test suite after your turnip changes to introduce authenticated-uid? [08:58] wgrant: I'd hope so, but it was a while back so I don't specifically remember. And I guess not given that you're asking the question ... [08:59] cjwatson: Heh, yeah, it was all very broken. [09:00] Fixed now, and I've adjusted setup.py so "setup.py test" runs the full suite now. [09:00] I'd been using "python -m unittest discover turnip", didn't realise "setup.py test" had been made to nearly-work. [09:07] wgrant: Thanks, sorry about that! [09:12] cjwatson: np, the fixes were easy. Just a bit confusing that the world was screwed when I was jujuing. [10:53] cjwatson: With that review out of the way, is anything left blocking you? [10:54] wgrant: Nope, thanks. [19:18] wgrant: did you get the turnipcake ports open? [19:21] lifeless: presumably you were referring to something in dulwich? Writing test helpers wrapping pygit2 atm to make git repo/object fixtures easier. On a tangential note, a lot of things I'm trying to achieve would be much easier in bzrlib! [19:22] blr_: yes === blr_ is now known as blr [19:23] I'll have a look through the dulwich source for inspiration, thanks [22:24] wgrant: my diff api MP has unmerged changes from api-ref (ready for re-review), perhaps just consider both in the new MP and I can delete the other? [22:30] blr: Ah, yeah, that probably makes sense. [22:30] blr: Sorry, got distracted by juju yesterday... [22:30] no worries - did you get turnipcake up in the end? [22:35] blr: Yep, found a few issues with both charm and code on the way, but I know my way around enough to fix the charms now. [22:35] The services framework stuff seems to make them muuuuch nicer. [22:35] (I created a whole lot of Asana tasks for most of the issues I found, as I blundered through) [22:36] wgrant: yes, I removed lots of boilerplate once I switched to the services framework. [22:40] wgrant: if turnip.endpoint was in /srv/envs it should have been available in the environment which will override the default set in the pyramid config [22:40] or am I missing something [22:41] turnip.endpoint in turnipcake.ini [22:41] blr: It didn't seem to be overriding it. I couldn't see code that read it. [22:41] wgrant: that's pyramid's default behaviour [22:42] orly [22:42] http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/environment.html [22:42] which is pretty sensible! [22:42] +1 pyramid [22:43] it will translate MY_ENV_VAR to my.env.var as well [22:43] a concern if it isn't actually working though :/ [22:44] blr: I don't think that works in general. [22:44] It would be rather unsafe if it did. [22:45] Yeah, the pyramid.config.settings does this sort of thing: [22:45] config_debug_auth = self.get('pyramid.debug_authorization', [22:45] config_debug_auth) [22:45] eff_debug_auth = asbool(eget('PYRAMID_DEBUG_AUTHORIZATION', [22:45] config_debug_auth)) [22:47] wgrant: ah I see, it is limited to a specific set of config values [22:49] welp, I can see why that wouldn't be working in that case, apologies. [22:52] might be worth reassessing the state of amulet, to have some basic integration tests in place for these relations [22:52] blr: Easy enough for me to fix, I suspect. [22:52] I still don't know quite where amulet fits with mojo. [22:53] no, nor am I... [22:53] blr: (I'm glad it's broken like this; Pyramid allowing any option to be overridden by a non-prefixed envvar would have made me switch away from it.) [22:53] wgrant: you're right, that would be a little terrifying.