[KNOWN ISSUE] Unexpected/unwanted crates in `Cargo.lock`

[abonander]

This issue is to serve as an aggregation point for issues like the following:

• sqlx without default-features puts unnecessary database crates in my Cargo.lock #2579
• Depends on all database crates regardless of features #2686
• Optional features are enabled even when not activated #2911
• SQLite is being selected as a feature when it shouldn't causing false failed to select version for libsqlite3-sys failure #2964
• All database cargo features are enabled when migrate cargo feature is enabled #3196
• Enabling migrate feature also adds mysql #3207
• uuid feature pulls in database specific code #3210
• Disable linking to libsqlite3 when default features are disabled and sqlite is not a feature. #3301
• Strange unwanted sqlite dependency when using sqlx 'chrono' feature along with rusqlite #3369
• default-features=false but chrono makes sqlx-mysql part of the Cargo.lock file #3538
• Sqlx depend on libsqlite3-sys if sqlite feature is disabled #3556

All of these issues have the same root cause: enabling a feature of SQLx that enables a weak feature, i.e. crate?/feature.

This will bring that feature's crate into the Cargo.lock which may make it appear that it is enabling code or dependencies that were explicitly not wanted (unused database drivers, dependencies with RUSTSEC advisories, etc.). In the case of #2964, it unfortunately appears that this can break dependency resolution since crates with native dependencies like libsqlite3-sys cannot be duplicated in the dependency graph.

This is a Cargo bug, not a SQLx bug.

We are using weak features for their intended purpose. The issue has been known upstream since 2022: rust-lang/cargo#10801

Don't comment here or on rust-lang/cargo#10801 unless you have something meaningful to add.

Complaining on the Cargo issue will just add noise and bury any productive discourse.

Read the discussion there and the proposed fix and its blockers to inform yourself of the situation before commenting.

Maybe you can be the one to fix it?

Just because it appears in the Cargo.lock does not mean it's getting compiled.

You can verify this yourself when performing a clean build of your project.

Interpret the output of any tool that just reads your Cargo.lock with a few grains of salt, and maybe help make sure that the authors of those tools are aware of this issue so they can take it into account.

Thank you.