Would be good to make sure we are using Cargo-feature-inheritance properly

[helio-frota]

We add and remove dependencies over time, but the reality is that we have no clear insight into whether:

• We are correctly propagating features to sub-crates ?
  • If not, does this impact build performance and/or binary size ?
• How can we ensure everything is in order ?
  • We can probably make use of cargo tree --depth 2 -e features to compare old and new results [?]

[helio-frota]

maybe https://github.com/taiki-e/cargo-hack can help us on this task

[helio-frota]

@chirino I found this error when running cargo-hack but I have no idea if that is wip or something

cargo hack check --each-feature --no-dev-deps
info: --no-dev-deps modifies real `Cargo.toml` while cargo-hack is running and restores it when finished
info: running `cargo check --no-default-features` on trustify-common (1/38)
error: feature `ai` includes `trustify-common/ai`, but `trustify-common` is not a dependency
  --> migration/Cargo.toml:13:6
   |
13 | ai = ["trustify-common/ai"]
   |      ^^^^^^^^^^^^^^^^^^^^^^

[helio-frota]

If not, does this impact build performance and/or binary size ?

super basic test with this repo which contains only clap as dependency, shows that the binary size continues the same but we have a bit ~0.2 seconds improvement when disabling default-features.

clap = "4"
Total units:	19
Max concurrency:	10 (jobs=12 ncpu=12)
Build start:	2025-02-24T20:46:42Z
Total time:	2.6s
-----
clap = { version = "4", default-features = false, features = ["std"] }
Total units:	12
Max concurrency:	5 (jobs=12 ncpu=12)
Build start:	2025-02-24T20:49:58Z
Total time:	2.4s

[helio-frota]

Noticed that we can skip this with cargo hack check --each-feature --skip ai 👍

[helio-frota]

@i386x I think we can change that initial confusing issue description to:

Can we use default-features = false on all dependencies and ensure that everything still works? If not, we need to add the exact feature(s) in the dependency declaration to compile.

I found a repo which contains a good amount of workspace members and it is using this technique:
https://github.com/kpreid/all-is-cubes/blob/main/Cargo.toml

👍

what do you think ?

[i386x]

Sounds good.

[helio-frota]

@i386x Would you mind if I take a look? I'll save the build timings beforehand to compare it later.
I'm curious to see if we'll have any development improvements or not, to see if it's worth the effort :)

[helio-frota]

Got some results without going deep:

• [before] Total time: 181.5s (3m 1.5s)
• [after] Total time: 165.8s (2m 45.8s)

15 seconds

In this link we have some dependencies that failed the build:
https://gist.github.com/helio-frota/701ae36d8a27135d814cfaeb7cb1c0cf

to see if it's worth the effort

for this first round, I don't think it worth, as It will "force" the team to use default-features = false and we have chances to add a single new dependency that adds 10+ seconds and we end up with a verbose Cargo.toml for almost nothing.

Something around one minute difference is good a deal for me.

A second round we would need to take a look at the remaining dependencies trying to enable specific features (some of them probably will not work even with that) and cargo clean ; cargo build and then cargo hack check --each-feature

screenshots

[helio-frota]

Crate	Time and features
actix-tls = "3"	0.7s 0.2s (28%) accept, connect, default, openssl
build-info = "0.0.40"	0.1s 0.0s (16%) default, runtime
build-info-build = "0.0.40"	0.4s 0.1s (30%) default, git, git2
build-info-common = "0.0.40"	0.6s 0.1s (9%) default, serde
deepsize = "0.2.0"	0.3s 0.0s (16%) cpe, deepsize_derive, default, derive, petgraph, std
itertools = "0.14"	2.3s 0.1s (6%) default, use_alloc, use_std
lenient_semver = "0.4.2"	0.1s 0.1s (50%) default, semver, semver_v100
opentelemetry = "0.28"	2.2s 1.3s (59%) default, futures-core, futures-sink, internal-logs, logs, metrics, pin-project-lite, thiserror, trace, tracing
opentelemetry-otlp = "0.28"	3.1s 1.6s (54%) default, grpc-tonic, http, http-proto, internal-logs, logs, metrics, opentelemetry-http, prost, reqwest, reqwest-blocking-client, tokio, tonic, trace, tracing
opentelemetry_sdk = "0.28"	10.5s 6.2s (60%) async-trait, default, glob, internal-logs, logs, metrics, percent-encoding, rand, serde_json, trace, tracing
roxmltree = "0.20.0"	1.2s 0.6s (49%) default, positions, std
rust-s3 = "0.35"	12.7s 7.6s (60%) default, fail-on-err, futures, hyper, hyper-tls, minidom, native-tls, tags, tokio, tokio-native-tls, tokio-stream, use-tokio-native-tls, with-tokio
schemars = "0.8"	3.2s 1.6s (50%) default, derive, schemars_derive, url
sea-orm-migration = "1"	3.3s 0.4s (11%) clap, cli, default, dotenvy, runtime-tokio-rustls, sea-orm-cli, sqlx-postgres, with-uuid
sea-query = "0.32.0"	5.8s 3.0s (51%) backend-mysql, backend-postgres, backend-sqlite, bigdecimal, chrono, default, derive, hashable-value, ordered-float, postgres-array, rust_decimal, sea-query-derive, serde_json, thread-safe, time, uuid, with-bigdecimal, with-chrono, with-json, with-rust_decimal, with-time, with-uuid
serde = "1.0.183"	4.2s 0.2s (5%) alloc, default, derive, rc, serde_derive, std
strum = "0.27.1"	0.1s 0.0s (15%) default, derive, std, strum_macros
utoipa = "5.1.3"	7.5s 3.9s (52%) actix_extras, default, macros, serde_yaml, time, url, uuid, yaml

probably we don't even need a second round check...in an imaginary world if we delete all those dependencies above we save ~50 seconds, since deletion not going to happen, then for me we can close this issue.

And here the 20 slowest ones, some of them are not declared dependencies.