Allow specifying target semver ranges

[CAD97]

Especially for reproducable CI builds, it would be useful to be able to specify the desired version range to install-update to. Currently, if I want to get updates within a semver range, my only option is to cargo install --version ^0.5 --force tarpaulin (to pick an example). I'd like to be able to cargo install-update --allow-no-update --version ^0.5 tarpaulin and let install-update handle not reinstalling it if it's been cached.

Design

A new --version option is added. It takes a VersionReq specified in the same format as cargo-install's --version option. If --version is specified, exactly one package must be specified.

If the installed version is the same as the latest published version within the specified version requirement, no action is taken. If a later version is available, it is installed by providing the --version option to cargo-install.

Implementation

(Note, I haven't seen how cargo-install-update is implemented, so I'm trying to keep this high-level enough to be applicable.)

Add a new --version option. This option takes an object of type semver::VersionReq. For full compatibility with cargo-install, it should be attempted to parse as an exact semver::Version if it doesn't start with one of =, >, <, ~, or ^. This can be decided for or against externally to what cargo-install does, as this is a separate command with different meaning.

When this --version option is present, fail early with an error message if more than one package are provided as trailing arguments.

Rather than determine the latest semver version as the target version, first filter the list of available versions on the version requirement provided, then select the latest version. Proceed normally with the new target version.

This may require renaming the Latest column to Target or something similar when --version is provided.

[nabijaczleweli]

Check latest master.

As for the design-thingy – full of specialcases and completely ignores the current infrastructure for setting per-package config, so it obv didn't go in.
As for compatibility with cargo-install – I harbour a deep-seated hatred for cargo's CLIs (unintuitive at best, bloody useless at worst), so that is not and has never been a priority (also consider how cargo-update solves a completely different problem domain).

[CAD97]

Makes sense. I just sort of spitballed a rough design expecting further refinement.

I'm glad to see this is available now!

[nabijaczleweli]

Right, so does it behave as you'd expect? If so, I'm gonna release it.

[CAD97]

I'll get a chance to try it out this evening, right now I'm limited to just looking at the patch on my phone.

The one edge case I'm worried about and tried to address in my sketch is specifying a version requirement and multiple crates. So maybe -a --version ^1.0 for example. Version is a by-crate status, not a general setting.

I can't tell exactly how master behaves without trying it out, so I will this evening. I've now circled around and repeated myself so I need to go do what I'm supposed to be doing :P

[nabijaczleweli]

So, "this evening" was a good four months ago – how was it?

[CAD97]

I'm so sorry about the delay, obviously a series of other things appeared and delayed me.

I actually can't install cargo-update right now because something about my Visual Studio setup is messed up, though, and libssh-sys won't build because of a CMake error: could not find any instance of Visual Studio.

[nabijaczleweli]

(Temporarily marking as external 'till that VS issue is resolved)

[nabijaczleweli]

@CAD97 bump