A method to update manifest version requirements (like cargo-edit's cargo-upgrade)

[Milo123459]

Problem

I had a crate that was defined in my projects Cargo.toml, it updated the version in the Cargo.lock, but not the Cargo.toml

Proposed Solution

It would be cool if cargo update also updated Cargo.toml if applicable.

Notes

No response

[epage]

I do not know if there is a dedicated issue for this but I plan to follow up on the cargo-add issue by merging other cargo-edit subcommands, like cargo-rm and cargo-upgrade.

cargo-upgrade is probably the least defined for what it will look like merged with questions like

• Should it be a separate command or a flag on cargo-update?
• Should --skip-compatible be a default? the only behavior?

Something that someone can do to help is to scour other language packaging tools for existing precedence in how they handle cases like this like the cargo-add PR does.

[epage]

Hmm, this issue is more about cargo update updating both files at once which is a subset of cargo upgrades behavior and might be part of the subset we don't merge immediately, so this probably isn't the best issue for tracking the cargo-upgrade integration

[epage]

#12425 was created specifically for incompatible version upgrades.

The FCPed proposal intentionally left this use case out

Somewhere between deferred and rejected (speaking for myself): Support in cargo update for writing to the manifest for non-breaking changes, like bulk compatible upgrades of version requirements (ie a -save flag) which was one of our lower priority workflows. A --save flag is more about updating versions for your dependents, which while important for having valid lower-bounds on version requirements, doesn't fit with the existing model of cargo update. Maybe in the future we can find a way to express this in cargo update that fits with how it works or maybe another command can take on this role. We just aren't wanting to distract our efforts for handling most of the use cases to handle this one.

See also https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-to-prepare-it-for-merging/17101

[epage]

In the past, we talked about a --save flag. As pointed out in that Internals thread, this seems to align with npm update

Note that by default npm update will not update the semver values of direct dependencies in your project package.json, if you want to also update values in package.json you can run: npm update --save (or add the save=true option to a configuration file to make that the default behavior).

This sounds like our case. Not being familiar with that ecosystem, I can't say whether there are semantics differences that could affect its use as prior art.

Not seeing any other relevant prior art from the tools sampled for cargo add (#10472).

[epage]

Potential solutions

Regardless of solution, we need to consider

• What version requirement operators should be changed and with what semantics?
  • cargo-edit's logic (https://github.com/killercup/cargo-edit/blob/d395bc51bf1fd7b97edeabadbb1df78d83643f03/src/version.rs#L144-L208) and examples (https://github.com/killercup/cargo-edit/blob/d395bc51bf1fd7b97edeabadbb1df78d83643f03/src/version.rs#L295-L413)
  • Can not do some now but add it later without being a breaking change?
  • Can we change the semantics later without it being a breaking change?

--save

Semantics:

• Literally: raise lower bounds of version requirements to make the versions in Cargo.lock to be the minimal version.
• Literally: Update not just for me but my dependents
• Semantically: Unblock access to new functionality

Naming:

• --save is used by npm update
• But its already "saved" in the lockfile
• Modifying lower bounds is not the same thing as "saving"

Which packages should be affected?

• Only those selected by the user
• Only those that actually got updated
• All

Workfow impact

• Editing Cargo.toml, cargo add changing a transitive dependency, etc will cause a mismatch
  • if we also added a flag to cargo add, you wouldn't know you need it until you ran the command and what to name it becomes harder
• No way to --save without doing a dependency update
• Requires always remembering the flag

Config

Similar to --save in semantics and in issues. Could also apply to cargo add

If we also do --save, we need a --no-save or --save=false

• I vaguely remember seeing guidance to avoid --no- flags after I added cargo add but I don't remember where

Workfow impact

• Editing Cargo.toml will cause a mismatch
• Some projects want to minimize version req changes to reduce Cargo.toml merge conflicts (they are fine blowing away Cargo.lock on conflict).
  • These projects could just choose to not set the config.
  • Similar for people who maintain two lockfiles

"lockfile higher than version reqs" lint

With a cargo fix to adjust version reqs

Do we go as far as cargo update and cargo add seeing the presence of the lint and auto-fixing?

• Would this do dirty tracking like cargo fix or not like cargo add, cargo remove, and cargo update

Workfow impact

• Editing Cargo.toml will cause a mismatch but users will get a warning about it with a suggestion of a command to fix it
• Some projects want to minimize version req changes to reduce Cargo.toml merge conflicts (they are fine blowing away Cargo.lock on conflict).
  • cargo update auto-fixing would be a problem but so would --warnings=deny causing their CI to fail, so they probably don't want this as a warning
  • There is a missing lint level that could help these people, see https://internals.rust-lang.org/t/forbid-deny-warn-allow-and-notice/19986
  • Similar for people who maintain two lockfiles

[epage]

At #5657 (comment), I bring up an idea that came up in a Cargo team meeting for us to develop this feature in place of -Zminimal-versions