Use HTTPX exclusively, sender changes

[felix-hilden]

From #131. When Httpx is stable, we could drop Requests and use it exclusively for senders. Currently it is used for async, which is beyond Requests' capability. There would be less hassle with converting between the two libraries.

[felix-hilden]

HTTPX 1.0 has been pushed to "mid-2020", and they are now working on 0.13. We might want to release our 2.0 sooner. Our 3.0 will likely be less breaking than 2.0, so things should go a bit smoother that time around.

Alternatively, we could simply adopt the current version. I'm not sure how mature they are, but our use case is pretty simple. I'll investigate a bit. At least 0.12 broke nothing for us.

[felix-hilden]

We'll stay with Requests and HTTPX for now.

[felix-hilden]

Looks like a 0.14 will be released before 1.0 as well. I think our 3.0 will wait for HTTPX to be stable. Surely it will come soon enough and the only other item on the changelist is PKCE (#193).

[felix-hilden]

We should also really consider whether all the different types of senders are necessary. There's something to be said about not even offering transient and singleton senders. I can not conjure an example where transient senders would be useful beyond debugging. Similarly, having multiple instances of Spotify should be rare, as we already offer options for swapping tokens. And those rare cases can definitely deal with using default sender instances or passing clients around.

Having senders is fine in my opinion, rather than using e.g. caching and retry arguments in the client directly, because that allows users to build their own. But this idea could be even expanded. Currently we pass requests.Request to senders. If we were to pass request parameters, users potentially even use different libraries in place of HTTPX without translating between httpx.Request and whatever they are using, like we have done so far. And indeed we cannot pass a request around, because then client options are not merged with the request as it is being sent (encode/httpx#1152).

[felix-hilden]

So, given the absence of requests.Session.prepare_request() and the fact that pre-built HTTPX requests are sent as-is, we have three options.

• Change interface from Request -> Response to method, url, headers, ... -> Response, or even -> code, headers, json or such, allowing for wildly custom senders. This complicates caching a bit.
• Expose httpx.Client.build_request through senders for our clients to build requests with.
• Implement our own light request and response containers. They would need:

Request

• method
• url
• params
• headers
• data

Response

• url (with params)
• headers
• status_code
• json method (that maybe returns None when no content)

Honestly, I'm not sure, but I think exposing build_request through senders is my least favorite. I'm flipping between the simpler interface that using a custom request-response would provide versus the implementation simplicity of a list of values.

[felix-hilden]

I'm leaning towards using our own request and response wrappers, for simplicity.

We could also get rid of sender options. Now they are a bit unintuitive. Again, having multiple senders instantiated is not really expected. And with the adoption of HTTPX, its Client can be passed with all options already set, with no need of passing parameters to each request. Removing all options would be a welcome simplification.

[felix-hilden]

Here's a summary of the proposed changes:

• Drop Requests, use HTTPX only
• Define custom Request and Response wrappers to be used in the sender interface
• Remove all sender options
• Remove transient and singleton senders, rename persistent senders as the former bases SyncSender and AsyncSender
• Inherit web exceptions from builtin Exception rather than Requests' or HTTPX's top exception
• Clients inherit from ExtendingSender
• CachingSender arguments are in the same order as RetryingSender

[felix-hilden]

Upgrading the HTTPX dependency to 1.0 is the only thing left to be done now. It's a check in #202.