Usage
See the next section for details.
-
Add to
dependencies:[] # ... = { = "0.1", = true } -
Activate one of
io_*feature flags: -
Depending on the use case, enable some inheritied features:
aws-lc-rsaws_lc_rsearly-datafipsloggingringtls12
-
Write your code with
anysc-rustlsas with{tokio, futures}-rustls.
What this does?
Just reexporting all the items of one of
based on the io_* feature flag selected.
The point is that this is a crate: it enables, for some (maybe niche) crates that
- support multiple async runtimes over different async IO interfaces
(
tokio::io,futures::io) - AND optionally provide rustls-powered TLS functionality
behind a feature flag (like
tls)
, to switch {async crate}-rustls dependencies without any needless dependencies.
Problem
That's impossible by other way: if simply having a submodule reexporting
tokio-rustls and futures-rustls conditionally with respective feature flags (like tokio-io, futures-io),
indeed it works, but the crate's [dependencies] will be like
[]
= { = true, = ... }
= { = true, = ... }
[]
= ...
= ...
= ...
Here, how we setup the features?
-
tokio-io = if "tls" ["dep:tokio-rustls"]+futures-io = if "tls" ["dep:futures-tls"]impossible.
-
tls = if "tokio-io" ["dep:tokio-rustls"] else if "futures-io" ["dep:futures-tls"]impossible.
-
tls = ["dep:tokio-rustls", "dep:futures-rustls"]works, but one of them must be needless.
So it's impossible to avoid undesired dependencies in this way.
Solution
However, it's enabled by a crate-level shim layer as this crate:
[]
= { = "0.1", = true }
[]
= ["dep:anysc-rustls"]
= ["anysc-rustls?/io_tokio", ...]
= ["anysc-rustls?/io_futures", ...]
Yes, that's done by the <crate>?/<feature> syntax!