Should `std` enable `rkyv` & others?
Opened this issue · 3 comments
db-tokio-postgres
depends on std
which, according to README.md
, disables no_std
support, but it seems to enable/include various optional dependencies.
This happens because db-tokio-postgres
depends on the std
feature, which then activates the optional dependenciesborsh
, rand
, rkyv
, serde
and serde_json
.
Is this intentional? I get that db-tokio-postgres
can't work in no_std
, but why does std
have to enable the rkyv
(and other) features?
I don't think that is how our features set up. Do you have an example repo where you're seeing incorrect behaviour?
We use <dep>?/std
for our dependencies, which enables their std
features if those dependencies are already enabled.
If you're just seeing this in our Cargo.toml, then perhaps that is the cause of confusion?
I think this is probably related to how cargo
reports optional weak dependencies (e.g. metadata
). This is was previously discussed a little bit in regards to weak dependencies for Rust Decimal in issue #588.
The cargo lock behavior is further discussed within the cargo
project here: rust-lang/cargo#10801
I think the key takeaways here:
- For what it's worth, we do seem to be using the feature correctly
cargo tree
should resolve the dependency tree correctly (please let us know if you have alternative results).- The
cargo.lock
file may appear to include features not required due to the linked cargo issue.