Consider pushing back on UDS support.

[tomchristie]

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.)

[tomchristie]

Milestoning for consideration with 0.11.0

[florimondmanca]

We won't have UDS support in the sync case.

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]

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?

[tomchristie]

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 urllib3 although... urllib3/urllib3#1469

Also our UDS support doesn't appear to be supported on proxies.

[tomchristie]

We can absolutely pass on this if I'm being too brutal in the name of "keep the scope minimal".

[tomchristie]

@florimondmanca Will leave this to your call.

[florimondmanca]

@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.

[tomchristie]

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]

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]

Cc'ing @lundberg on this one as well…

[tomchristie]

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.