[17:54] <lazyPower> wgrant: That's in context of the python launchpadlib no?
[18:05] <lazyPower> OH! each resource has a ws.op parameter that gives you access to the subresources! AWESOME! *lightbulb*
[18:06] <lazyPower> or not, this is error output :(
[18:49] <cjwatson> ws.op is how method names are passed to the LP webservice
[18:49] <cjwatson> basically
[18:52] <cjwatson> 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] <cjwatson> For example that gives me http://paste.ubuntu.com/7485053/
[18:53] <cjwatson> (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] <lazyPower> cjwatson: i'm building a ruby gem with an attempt to get feature parity with pythons launchpadlib
[19:25] <lazyPower> 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] <lazyPower> cjwatson: actually i spoke too soon. I'm making really good headway with the readonly client code
[20:07] <lazyPower> 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] <ehoover> could someone possibly investigate why https://code.launchpad.net/~vcs-imports/wine/master-git isn't updating?
[21:29] <cjwatson> lazyPower: ah, right, writing bindings for another language is one of the few good reasons :)
[21:29] <cjwatson> lazyPower: I don't speak ruby so probably not much point in me looking too hard, though
[21:29] <cjwatson> lazyPower: but good luck
[21:32] <cjwatson> 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] <cjwatson> it's probably not a good idea to rename things as people are going to work off the +apidoc and renaming confuses things
[22:48] <lazyPower> cjwatson: hmm good feedback.
[22:49] <xnox> lazyPower: well, first thing that launchpadlib does is download the wadl description of the API in XML.
[22:49] <xnox> lazyPower: it's not quite standard Java WADL, thus a special parser is required.
[22:50] <lazyPower> xnox: thats why i'm avoiding that file like the plague
[22:50] <xnox> 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] <xnox> lazyPower: yeah, i'm trying to write launchpadlib in python3, and so far i was avoiding that file as well.
[22:50] <lazyPower> xnox: Why isn't it an a-typical WSDL then?
[22:50] <lazyPower> its a standard document :|
[22:51] <lazyPower> then i could have done something like, import savant and consumed that wsdl and called it a day.
[22:52] <xnox> 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] <lazyPower> 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] <lazyPower> that's on the map for 2.x
[22:52] <xnox> 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 <wadl:_tag_>
[22:53] <xnox> lazyPower: so when i tried to validate it with some 3rd party wadl parsers it failed.
[22:53] <lazyPower> I may be letting my soap show....
[22:53] <xnox> lazyPower: and there is no python3 wadl parsers at all.
[22:53] <lazyPower> since wsdl is specific to soap
[22:54] <xnox> 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] <lazyPower> Yeah. I'm going for all the low hanging fruit that I can manage before I dive into the non-standard implementations.
[22:54] <xnox> lazyPower: use plaintext signatures, and at the last token exchange one _must_ use body signature authentication method at the moment.
[22:55] <lazyPower> 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] <xnox> lazyPower: go for annnonimous things for now.
[22:55] <lazyPower> oh wow, thats... interesting.
[22:55] <lazyPower> let me note that so if i run into it i know why, because body signature would throw me
[22:55] <xnox> yeah, i have a fix for it, but it fails test-suite and opens up a huge security hole =(
[22:55] <xnox> so not merged yet. status - work in progress.
[22:56] <xnox> lazyPower: let me paste you a script of mine.
[22:58] <xnox> lazyPower: http://paste.ubuntu.com/7485944/ -> that should work with unreleased requests_oauthlib under python3.
[22:59] <xnox> 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] <lazyPower> notbadobama.gif
[23:05] <wgrant> xnox: What's non-standard about our WADL?
[23:05] <wgrant> It has some extensions, but it shouldn't be otherwise non-standard.
[23:05] <wgrant> Also, WADL, not WSDL. We're not a SOAP API.
[23:06] <wgrant> lazyPower: You really need to not hardcode the structure of the API. Things are added frequently and occasionally changed.
[23:09] <lazyPower> I would have thought that if something broke, it would constitute a new version of the API
[23:10] <lazyPower> s/broke/changed that dramatically/
[23:10] <xnox> lazyPower: not really, since the clients are meant to download the wadl and act according to what they've downloaded.
[23:11] <xnox> 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] <xnox> 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] <lazyPower> ^ thats pretty much the route i'm taking
[23:13] <xnox> s/python3/ruby/ =)
[23:14] <lazyPower> I'm in a discovery session with pry scoping the wadl gem though
[23:14] <lazyPower> if this reduces overall code, i'll go that route. But i'm concerned with your reprted findings on python3 wadl parsers
[23:15] <wgrant> xnox: Erm, that's pretty basic XML
[23:16] <wgrant> We bind the WADL namespace to xmlns:wadl
[23:16] <xnox> wgrant: i see. well i must have been using crappy parser then.
[23:18] <xnox> didn't know about namespaces, read up on it now. looks useful, yet i've never seen/needed to use them.
[23:20] <wgrant> 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] <wgrant> The entire client stack is in lp:wadllib, lp:lazr.restfulclient, and lp:launchpadlib
[23:21] <wgrant> Roughly 1000, 2000 and 1500 lines of Python each.
[23:41] <xnox> 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] <wgrant> Yeah, the problem is that lazr.restfulclient has a test dependency on lazr.restful.
[23:41] <wgrant> 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] <xnox> thanks for pointers to these, looks very good and small indeed.
[23:42] <xnox> wgrant: hm..... can i keep lazr.restful in python2, yet have lazr.restfulclient in python3 talking to it?
[23:42] <xnox> it's all bytes over the wire.....
[23:42] <wgrant> xnox: It requires changes to the test suite, but that's what we should be doing, yes.
[23:43] <wgrant> Currently it relies on being able to run lazr.restful in-process, and obtains it using buildout.
[23:47] <xnox> 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] <xnox> (requests_oauthlib was hilariously reusing oauthentication upon redirect resulting in denies)
[23:49] <wgrant> Yeah, a couple of libraries in other languages have had that same problem.
[23:49] <wgrant> And that one's *not* our fault :)
[23:51] <xnox> i loved the response "most other sites, do internal resolution, and return correct data without redirecting"
[23:51] <xnox> 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] <xnox> oh if you are online and working, I should be asleep long time ago!
[23:56] <xnox> good night.
[23:57] <wgrant> Heh, night