Merge lp://staging/~jml/piston-mini-client/split-request-base-1041825 into lp://staging/piston-mini-client
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Anthony Lenton | ||||
Approved revision: | 81 | ||||
Merged at revision: | 64 | ||||
Proposed branch: | lp://staging/~jml/piston-mini-client/split-request-base-1041825 | ||||
Merge into: | lp://staging/piston-mini-client | ||||
Diff against target: |
778 lines (+444/-184) 4 files modified
piston_mini_client/__init__.py (+427/-182) piston_mini_client/tests/test_failhandlers.py (+15/-0) piston_mini_client/tests/test_log_to_file.py (+1/-1) setup.py (+1/-1) |
||||
To merge this branch: | bzr merge lp://staging/~jml/piston-mini-client/split-request-base-1041825 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Anthony Lenton | Approve | ||
Review via email: mp+124464@code.staging.launchpad.net |
Commit message
Add PistonRequester, enabling access to piston_mini_client functionality on a URL-by-URL basis
Description of the change
PistonAPI does two really useful things:
1. It makes it really easy to define a Python front-end for an HTTP API
2. It has a bunch of stuff to make doing HTTP requests easier
Sometimes, especially with callback services like pkgme-service, it would be really really useful to do 2. without doing 1. If you take a look at pkgme-service, you'll see code written by the original author (hello achuni!) that duplicates stuff going on in piston-mini-client.
This branch extracts that core, requesting logic into a base class and make PistonAPI subclass it. The base class is called PistonRequester (better names welcome).
Backwards compatibility has been preserved. Everything that subclasses PistonAPI today should still work after this change lands.
I've also changed setup.py to use setuptools, so I could run tox in a virtualenv.
Thanks,
jml
On 2012-09-14::
16:48:19 <achuni> jml: I thought PistonAPI was going to use PistonRequester as a client in the end? ble._as_ serializable. .. I'm not sure that's the recommended way, but it's what was done last time
16:48:33 <achuni> (or did we agree to go the other way around in the end?)
16:48:59 <jml> achuni: you mean, use composition instead of inheritance?
16:49:04 <achuni> yep
16:49:51 <jml> achuni: I'd be very happy to do that. It'll mean potentially breaking backwards compat w/ existing PistonAPI users
16:50:21 <jml> achuni: or alternatively wrapping every existing method (e.g. _prepare_headers, _get_proxy_info, ...)
16:50:25 <achuni> jml: even if you leave the current _get / _post / ... methods there?
16:50:35 <achuni> ah, right
16:50:36 <achuni> hm
16:50:39 <jml> achuni: your call.
16:51:38 <achuni> jml: yep, we'd need to wrap all methods, I think... I'd say the wrappers can be deprecated immediately
16:52:23 <jml> achuni: want warnings for the deprecations, or are docstrings enough?
16:52:52 <achuni> jml: like PistonSerializa
16:53:11 <jml> achuni: cool. I'll do that then.
I've now done this. I haven't cleared up the deprecation warnings in the tests.