Should `std` enable `rkyv` & others?

paupino / rust-decimal

Decimal number implementation written in pure Rust suitable for financial and fixed-precision calculations.

https://docs.rs/rust_decimal/

MIT License

1.03k stars 182 forks source link

Should `std` enable `rkyv` & others? #686

Open the-kenny opened 1 month ago

the-kenny commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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: https://github.com/rust-lang/cargo/issues/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.