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

Activity

1. Milo123459

   added

   C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

   on Mar 22, 2022
2. epage commented on Mar 22, 2022

   

   epage

   on Mar 22, 2022

   Last edited by epage

   Contributor

   More actions

   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.
3. epage

   added

   A-new-subcommandArea: new subcommandArea: new subcommand

   Command-update

   on Mar 22, 2022
4. bors

   added a commit that references this issue on Apr 18, 2022

   Auto merge of #10472 - epage:add, r=ehuss

   ...

   6a4d98d
5. epage

   changed the title [-]Can `cargo update` update a dependency specification in Cargo.toml?[/-] [+]A method to update manifest version requirements (like cargo-edit's `cargo-upgrade`)[/+] on Apr 22, 2022
6. epage commented on Aug 1, 2023

   

   epage

   on Aug 1, 2023

   Contributor

   More actions

   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
7. epage commented on Aug 8, 2024

   

   epage

   on Aug 8, 2024

   Last edited by epage

   Contributor

   More actions

   #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
8. epage

   added

   S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

   on Aug 8, 2024
9. epage commented on Aug 8, 2024

   

   epage

   on Aug 8, 2024

   Contributor

   More actions

   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).
10. epage commented on Aug 8, 2024

    

    epage

    on Aug 8, 2024

    Contributor

    More actions

    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
11. epage commented on Aug 8, 2024

    

    epage

    on Aug 8, 2024

    Contributor

    More actions

    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