Httpx: Version 0.12

[tomchristie]

So, I've issued a first release of httpcore - the intent is that we should switch over from our existing dispatchers (urllib3 for sync, our own ConnectionPool for async) to the httpcore dispatchers (SyncConnectionPool and AsyncConnectionPool).

The benefits for us doing so would be:

• We'll have a really nice strict seperation of concerns between the networking layer, and the cilent smarts layer.
• We'll have consistent network behavior across both sync + async (rather than urllib3 in one case.)
  *Able to drop the urllib3 dependancy, although we'll keep the urllib3 dispatcher as an optional alternative.
• In a postion to make promote the dispatch interface into public API.
• Tighter management of connection pool state changes. Resolves #514, #283. (I'll also take a look at #282 at some point.)

I guess we're probably in a position to push for doing that in 0.12 release if we wanted, although it means significant churn so I think we should certainly issue a pre-release if that's what we want to do.

The #804 PR goes a long way towards switching around the interface to allow us to plug into it, although there's still a little more that'd need doing there (changing the url signature to Tuple[bytes, bytes, int, bytes], changing the init arguments for httpcore.AsyncConnectionPool somewhat.)

Other PRs that look like they ought to go in...

• [x] Drop backend from Client. #791
• [x] Fix data to not erronously accept dict-of-dicts. #811
• [x] Ensure that Client.close() closes proxies. #826

Any more?

We'd also need to drop UDS support if we want to get httpcore in. I should have pushed back harded on it in the first place - as nice as it is to have features++ it doesn't really make the "feature set we need to focus on for 1.0".

I'd also really appreciate anyone kicking the tyres of httpcore a bit. It could do with some documentation love, but there should be enough there for folks to give it a first try.

What do we think? Is this a sensible point to aim at switching out to our unasync'ed backend? Is there anything I'm missing in considering this for a 0.12 release?

[florimondmanca]

Awesome work on getting a first HTTPCore release out there!

I haven't been very active around here lately, but overall the plan proposed here sounds good to me.

Although I might be tempted to have the bunch of current PRs in a 0.12 release, and then bring HTTPCore and unasync etc in 0.13? My rationale here would be, "let's get as much out of the way before switching the internals to HTTPCore". Perhaps we've also got a bunch of small fixes here and there that might benefit from being release soon rather than waiting for HTTPCore?

We'd also need to drop UDS support if we want to get httpcore in.

Alright, yeah. The (scheme, host, port, path) form of the URL specified by httpcore doesn't fit the UDS, so I can see why. Fine to have that as third-party in the end I guess. :-)

[florimondmanca]

Ideally I'd like us to have #836 and then #23 (docs PRs) for the next release as well…

[victoraugustolls]

I could gladly help, if that’s desirable! I’m using httpx a lot in the place I work. All of our new miroservices use it (with FastAPI), and although I’m running into some problems that need better understanding, I would love to make this library the goto standard for http communication in the future for any python developer!

[florimondmanca]

Shold we consider resolving #302 part of the roadmap to 1.0?

[tomchristie]

@florimondmanca Nope not really. It's not an API blocker, so as much as I'd like to see any progress there, we've not got any need to block "this is the 1.0 API" against it.

[florimondmanca]

@tomchristie

Looks like all PRs that ought to get in for 0.12 got merged. We already have a few pending fixes that haven't been released yet (0.11.1 dates from Jan 17), eg #780, #803, #814, #819, #796.

I think we should issue 0.12 soon, and only look at unasync/bringing httpcore in for 0.13, WDYT?

[tomchristie]

Seems like a sensible tack, yup.