Should std enable rkyv & others?

[the-kenny]

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?

[Tony-Samuels]

I don't think that is how our features set up. Do you have an example repo where you're seeing incorrect behaviour?

[Tony-Samuels]

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?

[paupino]

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.