[17:54] wgrant: That's in context of the python launchpadlib no? [18:05] OH! each resource has a ws.op parameter that gives you access to the subresources! AWESOME! *lightbulb* [18:06] or not, this is error output :( [18:49] ws.op is how method names are passed to the LP webservice [18:49] basically [18:52] It's probably simplest to run the Python code with httplib2.debuglevel = 1, which will give you a dump of the request/response headers [18:52] For example that gives me http://paste.ubuntu.com/7485053/ [18:53] (IME driving the API by hand rather than via bindings is doing things unnecessarily the hard way, but maybe you have a good reason ...) [19:24] cjwatson: i'm building a ruby gem with an attempt to get feature parity with pythons launchpadlib [19:25] there's a goldmine of data in here, and i'm not writing my project in python - so the only feesable way to go about this was to start translating the api into another wrapper :) [20:06] cjwatson: actually i spoke too soon. I'm making really good headway with the readonly client code [20:07] https://github.com/chuckbutler/rlaunchpadlib - if you'd like to view the progress as it evolves. I'm open to any CR's / critique in what i have as a skeleton for the project. [20:56] could someone possibly investigate why https://code.launchpad.net/~vcs-imports/wine/master-git isn't updating? === zequence_ is now known as zequence [21:29] lazyPower: ah, right, writing bindings for another language is one of the few good reasons :) [21:29] lazyPower: I don't speak ruby so probably not much point in me looking too hard, though [21:29] lazyPower: but good luck [21:32] lazyPower: I'd generally recommend mimicking the property of launchpadlib where, as far as possible, all the API is server-side and the client code just defines how to translate your language's syntax into webservice calls - that is, I wouldn't expect to see names of specific methods in a bindings library [21:32] it's probably not a good idea to rename things as people are going to work off the +apidoc and renaming confuses things === nesthib is now known as Guest22056 === Guest22056 is now known as nesthib [22:48] cjwatson: hmm good feedback. [22:49] lazyPower: well, first thing that launchpadlib does is download the wadl description of the API in XML. [22:49] lazyPower: it's not quite standard Java WADL, thus a special parser is required. [22:50] xnox: thats why i'm avoiding that file like the plague [22:50] lazyPower: that xml is the goldmine, since one points the client-binding library at the url e.g. api.launchpad.net and then you can get resources, urls, methods, etc. [22:50] lazyPower: yeah, i'm trying to write launchpadlib in python3, and so far i was avoiding that file as well. [22:50] xnox: Why isn't it an a-typical WSDL then? [22:50] its a standard document :| [22:51] then i could have done something like, import savant and consumed that wsdl and called it a day. [22:52] lazyPower: assuming that "everyone can look at the docs online", but e.g. you do need to cache at least which methods are post/get/patch/update. Cause if one creates an object for e.g. ubuntu and somebody calls a method from the docs on it, you wouldn't want to guess each time if it's a get or post and just execute the right one. [22:52] xnox: thats fair. I have a v1 implementation roadmap of readonly, so i dont have to stress over the proper rest method to use, and i'm not mucking about with authenticated api oauth schenanigans. [22:52] that's on the map for 2.x [22:52] lazyPower: i don't know about savant, the only major difference is that instead of just using normal wadl xml tags like <_tag_>, it has [22:53] lazyPower: so when i tried to validate it with some 3rd party wadl parsers it failed. [22:53] I may be letting my soap show.... [22:53] lazyPower: and there is no python3 wadl parsers at all. [22:53] since wsdl is specific to soap [22:54] lazyPower: oh, the oauth shenaningans are also non-standard on launchpad. I've discovered that and submitted a fix, but that's not deployed yet. [22:54] Yeah. I'm going for all the low hanging fruit that I can manage before I dive into the non-standard implementations. [22:54] lazyPower: use plaintext signatures, and at the last token exchange one _must_ use body signature authentication method at the moment. [22:55] my use case really doesn't have need for any of the authenticated api routines, or put. Its all get, and public projects. [22:55] lazyPower: go for annnonimous things for now. [22:55] oh wow, thats... interesting. [22:55] let me note that so if i run into it i know why, because body signature would throw me [22:55] yeah, i have a fix for it, but it fails test-suite and opens up a huge security hole =( [22:55] so not merged yet. status - work in progress. [22:56] lazyPower: let me paste you a script of mine. [22:58] lazyPower: http://paste.ubuntu.com/7485944/ -> that should work with unreleased requests_oauthlib under python3. [22:59] lazyPower: but it does show required options & urls to use, and client tokens to request, and things to ignore (e.g. empty verifier, etc.) [23:01] notbadobama.gif [23:05] xnox: What's non-standard about our WADL? [23:05] It has some extensions, but it shouldn't be otherwise non-standard. [23:05] Also, WADL, not WSDL. We're not a SOAP API. [23:06] lazyPower: You really need to not hardcode the structure of the API. Things are added frequently and occasionally changed. [23:09] I would have thought that if something broke, it would constitute a new version of the API [23:10] s/broke/changed that dramatically/ [23:10] lazyPower: not really, since the clients are meant to download the wadl and act according to what they've downloaded. [23:11] wgrant: the tags used are not per spec, as far as i can see we prefix all tag names with "wadl:" when we shouldn't*. [*] shouldn't means that the parsers i've tried to use failed to parse it, yet they work fine against wadls as generated by common java-webapps. [23:12] and i've decided against rewritting a wadl parser in python3, and instead try to create python3 REST bindings using like standard library + requests and nothing else. [23:13] ^ thats pretty much the route i'm taking [23:13] s/python3/ruby/ =) [23:14] I'm in a discovery session with pry scoping the wadl gem though [23:14] if this reduces overall code, i'll go that route. But i'm concerned with your reprted findings on python3 wadl parsers [23:15] xnox: Erm, that's pretty basic XML [23:16] We bind the WADL namespace to xmlns:wadl [23:16] wgrant: i see. well i must have been using crappy parser then. [23:18] didn't know about namespaces, read up on it now. looks useful, yet i've never seen/needed to use them. [23:20] http://bazaar.launchpad.net/~lazr-developers/wadllib/trunk/view/head:/src/wadllib/application.py is our parser. We also have a client with a different API that doesn't use WADL at all, for testing the server code without launchpadlib: http://bazaar.launchpad.net/~lazr-developers/lazr.restful/trunk/view/head:/src/lazr/restful/testing/webservice.py#L227 [23:20] The entire client stack is in lp:wadllib, lp:lazr.restfulclient, and lp:launchpadlib [23:21] Roughly 1000, 2000 and 1500 lines of Python each. [23:41] right, but when barry tried to tackle porting the client stack it wound up in porting all the deps (lazr.*) which ultimately didn't work. [23:41] Yeah, the problem is that lazr.restfulclient has a test dependency on lazr.restful. [23:41] Which ends up pulling in a good portion of zope.app, despite the fact that lazr.restfulclient only needs to talk to lazr.restful over a network socket. [23:42] thanks for pointers to these, looks very good and small indeed. [23:42] wgrant: hm..... can i keep lazr.restful in python2, yet have lazr.restfulclient in python3 talking to it? [23:42] it's all bytes over the wire..... [23:42] xnox: It requires changes to the test suite, but that's what we should be doing, yes. [23:43] Currently it relies on being able to run lazr.restful in-process, and obtains it using buildout. [23:47] wgrant: i'd take bolting on crazy hacks to existing thing any day, over writing things from scratch. Just a trivial attempt at getting to +me resulted in bugs to: python requests, requests_oauthlib, and launchpad. [23:48] (requests_oauthlib was hilariously reusing oauthentication upon redirect resulting in denies) [23:49] Yeah, a couple of libraries in other languages have had that same problem. [23:49] And that one's *not* our fault :) [23:51] i loved the response "most other sites, do internal resolution, and return correct data without redirecting" [23:51] i am like "dude it's http, i can return any redirect i want" =)))) and then the fun bugs about serving different content from same URLs as recently demoend in django. [23:56] oh if you are online and working, I should be asleep long time ago! [23:56] good night. [23:57] Heh, night