We should support using httpx2 for sync-requests, it seems preferable to the old requests module. The text below is AI-generated.
Today the two clients accept different HTTP libraries:
- async (
caldav/async_davclient.py): niquests, then httpx2, then httpxyz,
then httpx - whichever imports first.
- sync (
caldav/davclient.py): niquests, then requests. The httpx family is
not an option at all.
So a project that already depends on httpx, and uses caldav synchronously, has to
pull in requests or niquests purely for this library. That is the same argument
as #690 - a library should prefer
the HTTP stack its consumer already has, rather than adding one - and it was
raised in #611 (comment):
Considering that, we should consider supporting httpx/httpx2 also for sync
operations. However, this will have to wait for 3.4 - at least.
Filing it so it does not get lost.
What is involved
The sync client is written against the requests API and niquests is a drop-in for
it, which is why that fallback was nearly free. httpx is not a drop-in:
requests.Session / niquests.Session vs httpx.Clientrequests.auth.AuthBase vs httpx.Auth - different contract, and
_HttpxBearerAuth already exists in the async client for exactly thisresponse.reason vs response.reason_phrase - caldav/response.py already
handles both- different exception hierarchies, which matters wherever the client catches
connection or timeout errors
close() vs close() is fine, but the context-manager semantics differ
The async client already carries most of these distinctions behind _USE_HTTPX;
the interesting question is whether the sync client should grow the same switch or
whether the two should share one thin transport layer. The latter is more work
and much better, and is probably a 4.0 conversation rather than a 3.4 one.
Not urgent
Nothing is broken; this is about not forcing a dependency on consumers who
already have one that would do.
We should support using httpx2 for sync-requests, it seems preferable to the old requests module. The text below is AI-generated.
Today the two clients accept different HTTP libraries:
caldav/async_davclient.py): niquests, then httpx2, then httpxyz,then httpx - whichever imports first.
caldav/davclient.py): niquests, then requests. The httpx family isnot an option at all.
So a project that already depends on httpx, and uses caldav synchronously, has to
pull in requests or niquests purely for this library. That is the same argument
as #690 - a library should prefer
the HTTP stack its consumer already has, rather than adding one - and it was
raised in #611 (comment):
Filing it so it does not get lost.
What is involved
The sync client is written against the requests API and niquests is a drop-in for
it, which is why that fallback was nearly free. httpx is not a drop-in:
requests.Session/niquests.Sessionvshttpx.Clientrequests.auth.AuthBasevshttpx.Auth- different contract, and_HttpxBearerAuthalready exists in the async client for exactly thisresponse.reasonvsresponse.reason_phrase-caldav/response.pyalreadyhandles both
connection or timeout errors
close()vsclose()is fine, but the context-manager semantics differThe async client already carries most of these distinctions behind
_USE_HTTPX;the interesting question is whether the sync client should grow the same switch or
whether the two should share one thin transport layer. The latter is more work
and much better, and is probably a 4.0 conversation rather than a 3.4 one.
Not urgent
Nothing is broken; this is about not forcing a dependency on consumers who
already have one that would do.