You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm unsure if this is intended behaviour, but it definitely doesn't seem like it should be.
Enabling some features on a crate (in my specific case, sqlx) seem to generate entries in Cargo.lock that specify dependencies that aren't actually part of what Cargo ends up resolving while building the project.
For example here is the Cargo.lock entry for sqlx when I select only the postgres feature (along with some other things like macros and runtime)
As you can see, sqlx-mysql and sqlx-sqlite (and their own dependencies) are not resolved. They are also not fetched while building. Why then are they part of the lock file?
This was reported in sqlxby someone else (probably because they too had a security advisory because sqlx-mysql depends on rsa), and one of the maintainers suggested that it may be a cargo bug.
And it does seem like a cargo bug to me because there should be no reason for these entries to be in the lock file if cargo never has to fetch them.
I'm not entirely sure that this isn't an issue with sqlx's feature configuration, and it is simply the fact that dependencies that are never resolved are included in the lock file that leads me to open this issue here.
oh, so it seems. I did try to look for duplicates but I suppose I didn't use the right keywords. I shall close this and watch the linked issue instead. Thanks for the quick response!
Problem
I'm unsure if this is intended behaviour, but it definitely doesn't seem like it should be.
Enabling some features on a crate (in my specific case,
sqlx
) seem to generate entries inCargo.lock
that specify dependencies that aren't actually part of what Cargo ends up resolving while building the project.For example here is the
Cargo.lock
entry forsqlx
when I select only thepostgres
feature (along with some other things like macros and runtime)And when I additionally enable the
chrono
feature, this happens:This is strange, because when I dig through the
sqlx
source, I see that all sub-crates use the?
syntax to ensure that the other drivers are excluded.The same is also confirmed when I do a
cargo tree
`cargo tree --target=all`
As you can see,
sqlx-mysql
andsqlx-sqlite
(and their own dependencies) are not resolved. They are also not fetched while building. Why then are they part of the lock file?This was reported in
sqlx
by someone else (probably because they too had a security advisory becausesqlx-mysql
depends onrsa
), and one of the maintainers suggested that it may be a cargo bug.And it does seem like a cargo bug to me because there should be no reason for these entries to be in the lock file if cargo never has to fetch them.
Steps
cargo init --lib
cargo add sqlx --no-default-features -F postgres,runtime-tokio,tls-rustls,macros
grep -A10 -B1 'name = "sqlx"' Cargo.lock
cargo tree --all-targets
(with-i sqlx-mysql
to have it fail)cargo add sqlx --no-default-features -F postgres,runtime-tokio,tls-rustls,macros,chrono
grep -A10 -B1 'name = "sqlx"' Cargo.lock
cargo tree
Possible Solution(s)
No response
Notes
I'm not entirely sure that this isn't an issue with
sqlx
's feature configuration, and it is simply the fact that dependencies that are never resolved are included in the lock file that leads me to open this issue here.Version
The text was updated successfully, but these errors were encountered: