Repository navigation
Consider pushing back on UDS support. #723
Description
I thiknk we should have pushed back on UDS support initially, and that bringing it in prior to 1.0 was probably a (minor) mistake.
- We're close to ratching back to 100% test coverage, and enforcing it, but UDS doesn't have complete coverage.
- We won't have UDS support in the sync case.
- We ought to be prioritizing requests/urllib3 parity plus async, HTTP/2. Our baseline for features at this point in time should generally be "If it's something that requests includes built-in, then we'll consider it, otherwise push back to later".
We're really close to having httpx in an API stable state, and I'm not convinced that built-in UDS support meets our cut-off lines for what we should have in, and what should be out (or should require third party support.)
Activity
lovelydinosaur commentedon Jan 6, 2020
Milestoning for consideration with 0.11.0
florimondmanca commentedon Jan 6, 2020
I don’t think that has to be the case. In #722 I initially mentioned that as TODO but added an implementation later, and it’s working great. :) Is it that urllib3 doesn’t provide UDS support?
florimondmanca commentedon Jan 6, 2020
I don’t think removing it and causing extra work for all before and then after 1.0 is worth it.
I really don’t feel like UDS support represents such a burden for us right now, does it? It feels pretty stable, “done”, and doesn’t represent a clear blocker wrt sync.
Plus, as we originally discussed in #511, it is non trivial to bring in as third party package without having the API look somewhat clunky. As a matter of fact, all network libraries we support do allow using UDS, so... why should we not have it in core?
lovelydinosaur commentedon Jan 6, 2020
I'm not absolute on it, but I don't think it really makes our cutoff points, and I think we should have pushed back on it at the time - it's not 100% clear that it's something we want to have in the core package or not. Being pretty agressive in keeping the scope as tightly bounded as possible is generally going to be a good tack for
httpx.Not currently supported by
urllib3although... urllib3/urllib3#1469Also our UDS support doesn't appear to be supported on proxies.
lovelydinosaur commentedon Jan 6, 2020
We can absolutely pass on this if I'm being too brutal in the name of "keep the scope minimal".
lovelydinosaur commentedon Jan 6, 2020
@florimondmanca Will leave this to your call.
florimondmanca commentedon Jan 6, 2020
@tomchristie It just feels wrong to me to remove working features just for the sake of it. And after re-reading discussions from #511 I'm still inclined towards thinking that HTTP over UDS has a place in core.
At the same time, if we're not willing to support it properly (I'm not particularly interested in UDS support either for my every day life using HTTPX), then we might end up with a half-baked solution, when third-party package could be more focused and feature-complete. (See also your note on our lack of support on proxies.)
So, eh… At least I'd like to see how a third-party UDS package would look like, to confirm that wouldn't be too painful to write and use, and that there aren't any particular blockers. After that, I can roll with dropping it, I think.
lovelydinosaur commentedon Jan 6, 2020
Well, on reflection I’m not sure that connecting to a proxy through UDS is something we’d ever care about supporting, so that one might be off-base.
florimondmanca commentedon Jan 6, 2020
Okay, I pushed httpx-unixsocket-poc. #729 shows the changes that were required so that the package does not reimplement too much stuff from scratch.
My mind is at ease, I think I'm ready to accept considering #726? 😄
florimondmanca commentedon Jan 7, 2020
Cc'ing @lundberg on this one as well…
lovelydinosaur commentedon Jan 7, 2020
I think we should probably punt on this for 0.11. We might??? want to consider it at some point, but let's keep the focus on getting our sync+async support in. We can then take our time over any remaining API decisions for 1.0.