Fixes #2.
Resolution, XRPC, OAuth, lexicon fetches and the space client all take the
caller's reqwest::Client rather than building one, so a consumer has to
construct a client of the same reqwest these crates were built against.
Nothing said which that was: the version lived only in a lockfile, and a
mismatch surfaces as "expected Client, found Client" with no hint that two
copies of the crate are in the graph.
Each crate that names a reqwest type in its public API now re-exports the
crate it compiled against, so a caller can reach the client through the library
instead of pinning a matching version by hand:
let http_client = atproto_identity::reqwest::Client::new();
| crate | public API that takes or returns a reqwest type |
|---|---|
atproto-identity |
resolve::*, web::query, webvh::query, plc::* (gated on resolve) |
atproto-client |
xrpc_call, dpop_call, get_json, get_bytes, HttpRecordResolver::new |
atproto-oauth |
oauth_init, oauth_complete, oauth_refresh, resources::* |
atproto-oauth-axum |
state::HttpClient(pub reqwest::Client) |
atproto-lexicon |
DefaultLexiconResolver::new, fetch_lexicon_from_pds, get_lexicon |
atproto-jetstream |
ArchiveClient::with_client, fetch_dictionary |
atproto-space-client |
SpaceSession, SpaceAccess, space_read_credential |
atproto-tap |
From<reqwest::Error> for TapError |
atproto-dasl |
fetch_verified_with_client (gated on the reqwest feature) |
atproto-pds |
notifier::build_client, migrate::source::http_client, PlcService::with_http_client |
atproto-client and atproto-oauth also re-export reqwest-middleware, whose
Error appears in their error enums.
Each re-export follows the feature that pulls the dependency in — resolve for
atproto-identity, reqwest for atproto-dasl — so a no-network build is
unchanged. atproto-record's lean_dependencies test still passes.
The atproto-identity README's resolution example now goes through the
re-export and says why.