Upgrade dependency to specific version

[jrobsonchase]

Pushing a dependency to the latest version isn't always the desired behavior. For example, if one of your crate's dependencies depends on an older version of error_chain than the latest, it can cause problems since you can end up with two incompatible versions of the generated types.

It would be nice to have an option to specify the version to upgrade (or even downgrade) to, either in the cargo-upgrade command, or in a new cargo-set-version command, preferably that would work for the entire workspace.

[ordian]

@jechas01 I think you can already use cargo add <crate> --vers <vers> for this, though it wouldn't work with workspaces.

[jrobsonchase]

Oh, does that update the version of existing dependencies? I was under the impression that the --vers flag for add was just to specify the version of new dependencies.

…

On Thu, Nov 16, 2017, 17:33 Andronik Ordian ***@***.***> wrote: @jechas01 <https://github.com/jechas01> I think you can already use cargo add --vers for this, though it wouldn't work with workspaces. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABe0rddo6wTgQH_diXff1rqLTBHkxYj-ks5s3Lg7gaJpZM4QhOeI> .

[ordian]

Yeah, we should probably document that: running cargo add <crate> will overwrite existing <crate> entry in Cargo.toml (with or w/o --vers flag).

[jrobsonchase]

Ah, ok, good to know. It would still be massively helpful to have it work for workspaces. For large multi-crate projects, managing duplicate dependencies can get cumbersome, and a way to ensure that the same version is used across all workspace crates would be awesome.

…

On Thu, Nov 16, 2017, 19:28 Andronik Ordian ***@***.***> wrote: Yeah, we should probably document that: running cargo add <crate> will overwrite entry in Cargo.toml (with or w/o --vers flag). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABe0rWBoBqgycsJfTHFeeroBkurQGtK3ks5s3NMbgaJpZM4QhOeI> .

[bjgill]

That's an interesting point. I've also been using cargo upgrade with a large workspace. I've had the same problem you did, and have also found upgrading single dependencies more often than the complete set.

Maybe we should change the CLI to something like:

Usage:
    cargo upgrade [options]
    cargo upgrade [options] <dependency> [--vers <version>]

Here, the default would remain unchanged, but the experience of upgrading a single dependency would be better (no longer need a -d), and you would be able to specify a version (allowing us to short-circuit crates.io).

We'd probably want to deprecate the old way of specifying specific dependencies (-d --dependency) and warn the user if they use that format.

Thoughts? I shouldn't think this should be too difficult, so I might look at implementing this over the weekend.

[bjgill]

I'm starting to look at this now. It probably makes sense to try and stick as close as possible to cargo update. As such, I think I favour:

Usage:
    cargo upgrade [options]
    cargo upgrade [options] <dependency>... [--precise <PRECISE>]
    cargo upgrade (-h | --help)
    cargo upgrade (-V | --version)

Options:
    --all                       Upgrade all packages in the workspace.
    --precise PRECISE           Upgrade dependencies to exactly PRECISE.
    --manifest-path PATH        Path to the manifest to upgrade.
    --allow-prerelease          Include prerelease versions when fetching from crates.io (e.g.
                                '0.6.0-alpha'). Defaults to false.
    -h --help                   Show this help page.
    -V --version                Show version.