starlette Fix httpx private api usage

Refs: https://github.com/encode/httpx/pull/3130

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

Mar 03 '24 09:03 karpetrosyan

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

Mar 03 '24 09:03 Kludex

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

Mar 03 '24 09:03 Kludex

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

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

Mar 03 '24 09:03 karpetrosyan

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

Mar 05 '24 16:03 lovelydinosaur

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

Ok. 👍

Mar 05 '24 17:03 Kludex

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

Ok. 👍

Wanna do it here @karpetrosyan ?

Mar 05 '24 17:03 Kludex

Wanna do it here @karpetrosyan ?

Yep

Mar 05 '24 18:03 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?

Mar 09 '24 16:03 karpetrosyan

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

Mar 09 '24 16:03 Kludex

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

Mar 09 '24 20:03 lovelydinosaur

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

We can't use that for type annotation. 👀

Mar 09 '24 20:03 Kludex

What's the plan here? @karpetrosyan

Apr 20 '24 07:04 Kludex

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?

Apr 20 '24 08:04 karpetrosyan

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.

Apr 20 '24 08:04 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)

Apr 20 '24 10:04 lovelydinosaur

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

Apr 21 '24 09:04 karpetrosyan

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

Jun 01 '24 13:06 Kludex