| lazyPower | wgrant: That's in context of the python launchpadlib no? | 17:54 |
|---|---|---|
| lazyPower | OH! each resource has a ws.op parameter that gives you access to the subresources! AWESOME! *lightbulb* | 18:05 |
| lazyPower | or not, this is error output :( | 18:06 |
| cjwatson | ws.op is how method names are passed to the LP webservice | 18:49 |
| cjwatson | basically | 18:49 |
| 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:52 |
| 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 ...) | 18:53 |
| lazyPower | cjwatson: i'm building a ruby gem with an attempt to get feature parity with pythons launchpadlib | 19:24 |
| 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 :) | 19:25 |
| lazyPower | cjwatson: actually i spoke too soon. I'm making really good headway with the readonly client code | 20:06 |
| 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:07 |
| ehoover | could someone possibly investigate why https://code.launchpad.net/~vcs-imports/wine/master-git isn't updating? | 20:56 |
| === zequence_ is now known as zequence | ||
| 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:29 |
| 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 | 21:32 |
| === nesthib is now known as Guest22056 | ||
| === Guest22056 is now known as nesthib | ||
| lazyPower | cjwatson: hmm good feedback. | 22:48 |
| 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:49 |
| 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:50 |
| lazyPower | then i could have done something like, import savant and consumed that wsdl and called it a day. | 22:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| xnox | lazyPower: let me paste you a script of mine. | 22:56 |
| xnox | lazyPower: http://paste.ubuntu.com/7485944/ -> that should work with unreleased requests_oauthlib under python3. | 22:58 |
| 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.) | 22:59 |
| lazyPower | notbadobama.gif | 23:01 |
| 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:05 |
| wgrant | lazyPower: You really need to not hardcode the structure of the API. Things are added frequently and occasionally changed. | 23:06 |
| lazyPower | I would have thought that if something broke, it would constitute a new version of the API | 23:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| lazyPower | ^ thats pretty much the route i'm taking | 23:13 |
| xnox | s/python3/ruby/ =) | 23:13 |
| 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:14 |
| wgrant | xnox: Erm, that's pretty basic XML | 23:15 |
| 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:16 |
| xnox | didn't know about namespaces, read up on it now. looks useful, yet i've never seen/needed to use them. | 23:18 |
| 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:20 |
| wgrant | Roughly 1000, 2000 and 1500 lines of Python each. | 23:21 |
| 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:41 |
| 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:42 |
| wgrant | Currently it relies on being able to run lazr.restful in-process, and obtains it using buildout. | 23:43 |
| 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:47 |
| xnox | (requests_oauthlib was hilariously reusing oauthentication upon redirect resulting in denies) | 23:48 |
| 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:49 |
| 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:51 |
| xnox | oh if you are online and working, I should be asleep long time ago! | 23:56 |
| xnox | good night. | 23:56 |
| wgrant | Heh, night | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!