[00:33] hello leonardr, are you around and could you please help me with a LP API change? [00:34] Is this the SP.branches dict? [00:34] I think that will be difficult or impossible; I don't know of any existing exported dicts that contain other entries. [00:34] wgrant: an attempt, yes. [00:34] http://pastebin.ubuntu.com/300148/ [00:35] this is the error I get during testing: http://pastebin.ubuntu.com/300150/ [00:36] That's what I expected. [00:37] hrm [00:37] lazr.restful doesn't treat dicts specially. [00:37] Normally when it sees an enum in a field it will stringify it, and only then hand it off to be JSON-encoded. [00:37] wgrant: aha [00:38] And I'm not sure if launchpadlib is set up to handle dict specifications in WADL. [00:38] al-maisan: i'm not really around but i can try to answer your question [00:39] unless wgrant already has [00:39] leonardr: thanks -- please see http://pastebin.ubuntu.com/300148/ [00:39] yes, i odn't think you'll have much luck exporting a dict [00:39] you can publish a named operation that returns a dict [00:39] There are existing named ops that return dicts. [00:39] Right. [00:39] OK [00:39] But I guess launchpadlib won't interpret any entry links inside them. [00:40] no, you'll just have a dict of strings to strings [00:40] I'll go down the named operation route then [00:40] So I guess just export a named op that takes a pocket. [00:40] al-maisan: you should be able to write a serializer [00:40] for dicts [00:40] leonardr: aha [00:40] leonardr: But won't that require client changes? [00:40] look in lazr.restful for other examples [00:40] OK [00:41] i don't think so. i think the client will see .foo as a dict [00:41] there might be problems changing the dict and sending it back [00:41] I mean, lazr.restful will serialise it and stop crashing, but the client will still just see strings. [00:42] leonardr: changing the dict and sending it back is not an issue here.. [00:42] wgrant: yes, the client will still see strings, but it's better than creating a named operation that will have the same problem [00:43] al-maisan: look in lazr/restful/marshallers.py [00:43] leonardr: thanks for the pointer [00:43] i guess i should leave so people don't think i'm still around [00:43] good night [00:43] Good night [00:45] I see a slight ordering issue here. [00:46] aha [00:47] wgrant: what do you mean? [00:48] al-maisan: Well, US people vanishing while you are still here. I make it early morning for you. [00:48] wgrant: yeah ;) [00:48] so still prodding my bug 456764: after teaching lazr.restful about timedeltas my trivial patch (adding two exported() calls) runs, I see the attributes show up in the apidoc (after I forced a regen of the wadl file), but I don't see them through launchpadlib. [00:48] Bug #456764: please expose builder queue state through the api [00:48] * al-maisan falls off the chair :P [00:49] I'm not sure if this is because I need to patch more of launchpad, the objects I'm accessing through launchpadlib don't actually have that attribute, or I need to regen some other file than the wadl [00:49] mzz: You've restarted your launchpadlib app? [00:49] my launchpadlib app is a script, so yes [00:49] (you need to re-create the Launchpad object) [00:49] let me pastebin some stuff [00:49] mzz: what if you browse the object in a browser? (add '/api/beta' to the front of the path to the object) [00:52] ah, estimated_build_duration does show up there but is None [00:52] huh, but buildduration shows up and isn't None [00:52] That's what I would expect. [00:52] They should be mutually exclusive. [00:52] Shouldn't they? [00:53] * wgrant checks the code. [00:53] not what I meant [00:53] I mean my launchpadlib script isn't seeing record.buildduration on https://api.launchpad.dev/beta/ubuntu/+source/pmount/0.1-1/+build/19 but my browser does see it on https://api.launchpad.dev/api/beta/ubuntu/+source/pmount/0.1-1/+build/19 [00:54] I think I'm missing a step or using a wrong url somewhere on the launchpadlib end then? [00:54] You removed and regenerated the *dev* WADL? [00:54] There are two different WADL documents. [00:54] ah, let's see [00:55] I removed wadl-development.xml, not wadl-testrunner.xml. After doing that and restarting launchpad my attribute showed up in launchpad.dev/+apidoc, which I figured was a good sign [00:55] do I need to do anything on the launchpadlib end? [00:56] I'm not running launchpadlib on the same host as launchpad [00:56] wadl-development.xml should be the right one. [00:56] Hmmm. [00:56] You don't have a launchpadlib cache set up, do you? [00:56] The etag of the object will not have changed, so a cache could break things. [00:56] I do! that's probably it, killing... [00:57] (and logging back in... is there a switch on launchpad to turn off access control if you're in a hurry? :) [00:58] Not without hacking launchpadlib and wadllib and lazr.restfulclient to use the browser webservice, and that makes leonardr angry. [00:58] But remember that you can save credentials. [00:58] that did it! thanks [00:58] Excellent. [00:59] (my script is using Launchpad.login_with(scriptname, service_root=...) to get a launchpad object, which apparently automatically caches not just credentials but also the wadl) [00:59] (I'm not even sure that's the right thing to call, it just looked like the easiest thing to call) [01:00] I normally use Launchpad.get_token_and_login, but I am probably behind the times. [01:01] well, that was pretty easy (after I'd found out I needed to remove the wadl by hand, but I guess that makes sense since detecting it's gone stale is painful) [01:01] (I mean the wadl on the server end) [01:02] now I just need to figure out how to test this stuff, and see if I can expose a bit of information about the queue too. === lionel_ is now known as lionel === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === henninge_ is now known as henninge