-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The usage of weak dependencies pollutes Cargo.lock
#11426
Comments
Is this kinda a duplicate of #10801? |
It is, indeed. |
@weihanglo I thought #10801 is about lock files including optional features of direct dependencies. Does it also include indirect dependencies? Note that in this issue, the lock file for
The number of lock file entries when The key part here is weak dependencies. It seems we are resolving the lock file as if none of those weak dependencies were weak. Re-opening for now so this doesn't get lost track of. If there was something I missed, we can always re-close. |
#10801 is
#11426 is
I didn't see the difference between them 🤔. |
Somehow I had missed the weak dependency aspect of the other one. I've re-titled it to call that out. Of course, if there is another angle to that that I missed, let me know and we can fix it :) |
Feel free to close if duplicated or if it is a "feature" of Cargo.
Problem
A feature declared with optional weak dependencies will unnecessarily pollute
Cargo.lock
with all the declared non-activated items as well as their transients, which is crazy.Take for example the rust_decimal crate. If declared as
rust_decimal = { default-features = false, version = "1.0" }
, thenCargo.lock
will contain 5 dependencies but if declared asrust_decimal = { default-features = false, features = ["std"], version = "1.0" }
, thenCargo.lock
will contain +40 dependencies.Version
The text was updated successfully, but these errors were encountered: