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
Currently, in one of my actix-based projects, running cargo upgrade attempts to upgrade my dependency on tokio to v1.x.
Given that the actix dependency still demands tokio v0.2.x, that means cargo upgrade tries to change the intended semantics of my Cargo.toml from "Depend on actix and give me access to the copy of tokio it pulls in" to "Depend on actix and pull in a separate copy of tokio for me to use".
Please add an option to only perform semver-breaking upgrades of direct dependencies when it would not increase the number of copies of a given dependency that will need to be compiled and linked.
(I give that very specific definition because I have other dependencies where upgrading two direct dependencies causes a shared transitive dependency to diverge and I just consider that a necessary evil.)
The text was updated successfully, but these errors were encountered:
ssokolow
changed the title
Option to skip upgrading dependencies if it would increase the number of copies to be built
Option to skip upgrading direct dependencies if it would increase the number of copies to be built
Jan 13, 2021
Reducing number of copies is something cargo add has also punted on, so rejecting that until we look at that problem more holistically.
For holding back dependency versions, cargo upgrade now doesn't upgrade non-default version requirements by default, assuming the user has a special reason to pin them. The user has to opt-in with --pinned. So the tokio upgrade can be resolved with that.
Now for automatically detecting the compatibility breaking is dependent on public/private dependencies (rust-lang/rust#44663). We'll want to update the tracking issue to include cargo upgrade.
Currently, in one of my actix-based projects, running
cargo upgrade
attempts to upgrade my dependency on tokio to v1.x.Given that the actix dependency still demands tokio v0.2.x, that means
cargo upgrade
tries to change the intended semantics of myCargo.toml
from "Depend on actix and give me access to the copy of tokio it pulls in" to "Depend on actix and pull in a separate copy of tokio for me to use".Please add an option to only perform semver-breaking upgrades of direct dependencies when it would not increase the number of copies of a given dependency that will need to be compiled and linked.
(I give that very specific definition because I have other dependencies where upgrading two direct dependencies causes a shared transitive dependency to diverge and I just consider that a necessary evil.)
The text was updated successfully, but these errors were encountered: