Open tomchristie opened 2 months ago
This comment makes a good case that this is an httpx
issue... https://github.com/encode/httpx/issues/3176#issuecomment-2226886331
@tomchristie , what do you suggest here?
Maybe we can remove httpx as a dependency for the TestClient
? It's always been confusing to install httpx for the testclient module for Starlette users. What do you think? Would that be bad for httpx?
Maybe we can remove httpx as a dependency for the TestClient?
Depends on exactly what you mean. It'd be an API breaking change, since it currently returns httpx types.
Something I do like about the existing test client is that it's mirroring using an actual Python client library to interact with the app.
One option could be a similar approach as eg. https://www.starlette.io/database/ - Don't have a dependency, but do document how to use httpx
as a test client. (We'd need to work through any functional additions that Starlette's TestClient provides. WebSockets anyone?)
Would that be bad for httpx?
We should aim for streamlined. (Consistent project guidelines, docs, tooling approaches etc.) We shouldn't aim for preferential treatment.
Let's go back to the original issue. What should Starlette do? Should httpx make types publich?
Really I'd like to tighten up the type definitions throughout, so that they're not needed...
Eg... aiming for this type of thing...
def request(
self,
method: str,
url: URL | str,
*,
content: typing.Any = None,
data: typing.Any = None,
files: typing.Any = None,
json: typing.Any = None,
params: QueryParams | Mapping[str, str] | None = None,
headers: Headers | Mapping[str, str] | None = None,
cookies: Cookies | CookieJar | Mapping[str, str] | None = None,
auth: Auth | None = None,
follow_redirects: bool | None = None,
allow_redirects: bool | None = None,
timeout: Timeout | float | None = None,
extensions: dict[str, typing.Any] | None = None,
)
What about the USE_CLIENT_DEFAULT
constant?
Also, I don't like that data
, content
, files
and json
have Any
.
Prompted by https://github.com/encode/httpx/discussions/3287
starlette
is currently using private imports fromhttpx
...https://github.com/encode/starlette/blob/c78c9aac17a4d68e0647252310044502f1b7da71/starlette/testclient.py#L500-L513
These are broken against the latest minor point release, which includes this (internal) refactoring... https://github.com/encode/httpx/pull/3245
It's possible that the path of least resistance for the short term is for
httpx
to re-includeURLTypes
, tho really we need to be making sure that downstream packages are not using private imports.Some prior discussion of this also at #2534.