Fix httpx private api usage

[karpetrosyan]

Refs: encode/httpx#3130

In some places, starlette uses imports from the private API, such as httpx._client, which will not work after mere of encode/httpx#3130.

[Kludex]

Actually, we use future annotations here. Nothing will break at runtime. 🥹🙏

[Kludex]

Is there any discussion about making types available on public modules?

[karpetrosyan]

Is there any discussion about making types available on public modules?

USE_CLIENT_DEFAULT was already public, we can use it directly from httpx.

[lovelydinosaur]

I'd suggest including the type definitions explicitly inside Starlette's codebase.

[Kludex]

I'd suggest including the type definitions explicitly inside Starlette's codebase.

Ok. 👍

[Kludex]

I'd suggest including the type definitions explicitly inside Starlette's codebase.

Ok. 👍

Wanna do it here @karpetrosyan ?

[karpetrosyan]

Wanna do it here @karpetrosyan ?

Yep

[karpetrosyan]

Do we really can add them into the starlette?
There are types that should be passed through the httpx, how we should handle them?

[Kludex]

For UseClientDefault we can't. It's a class, and is private. cc @tomchristie

[lovelydinosaur]

Noted. I guess there's type(httpx.USE_CLIENT_DEFAULT)

[Kludex]

Noted. I guess there's type(httpx.USE_CLIENT_DEFAULT)

We can't use that for type annotation. 👀

[Kludex]

What's the plan here? @karpetrosyan

[karpetrosyan]

What's the plan here? @karpetrosyan

I believe the best we can do here is to limit the upper version of HTTPX to the current version. Alternatively, we can maintain this import in HTTPX only for Starlette, but I don't believe this is a good idea. Is it critical that older versions of Starlette do not work with the most recent HTTPX?

[lovelydinosaur]

Shall we raise an issue for "3rd party packages using private imports of httpx"? That issue should describe what private imports starlette is currently using and why, so we can resolve whatever is causing that.

[lovelydinosaur]

(I say "3rd party" here because we shouldn't treat other encode packages differently from the rest of the ecosystem. Starlette's use of some private importing will be a really helpful thing for us to work through what we're getting wrong. I expect we need to think a bit more carefully about our typing and API expectations, let's see)

[karpetrosyan]

I have raised https://github.com/encode/httpx/issues/3176 to track all kinds of API needs in third-party packages.

[Kludex]

Since we are tracking the issue presented here on https://github.com/encode/httpx/issues/3176, I'll close this PR.