Specify minimum version for tools/dependencies

[roblabla]

Features Description
It'd be kinda neat to specify the minimum version of a tool we want. For instance, in SunriseOS, we now require cargo-xbuild 0.5.14, but cargo-make won't install the latest cargo-xbuild, it'll only install it if it wasn't found previously.

Describe the solution you'd like
Having some kind of [dependencies] section where we specify minimum version of the tools in the Makefile would be nice.

Alternatively, maybe cargo-make could always trigger an update? cargo install has an unstable flag to trigger an update instead of failing (cargo install -Z install-upgrade), but relying on unstable flags is kinda icky.

The version can be checked by looking at ~/.cargo/.crates.toml or ~/.cargo/.crates2.json, or it could be checked through some kind of regex match against binary --version ?

Code Sample

[dependencies]
cargo-xbuild = "0.5.14"

[task.xbuild]
command = "cargo"
args = ["xbuild"]

Should install latest cargo-xbuild if not present or if version installed is below the specified version.

[sagiegurari]

ya thats a great idea and i was thinking about it long time ago.
reason i didn't implement is that, there is no standard way to get the version value.
many crates support --version but not all and the output is not standard although very common.

but since i see i'm not the only one thinking about it, i'll add partial support, meaning if i can pull that info, i'll validate the min_version requested. if I can't, i'll ignore the min_version value.

i'm not sure i'll be checking the cargo.toml as those build dependencies would most likely not be defined there (for example clippy/rustfmt/....) but instead will be in the crate installation object under the relevant task.

[sagiegurari]

wait... didn't read your entire post :)
so there is a toml/json with the values... that's awesome. will investigate.

[roblabla]

was thinking the Makefile.toml itself would have a [dependencies] section, not the Cargo.toml. This way, "implicit" installations could still have a minimum version to check. But a dedicated install task would work too.

[sagiegurari]

@roblabla I just pushed this feature to the 0.22.0 development branch.
you can look at the docs on how to set it up at: Defining Minimal Version
If you can verify its ok and working good for you, it would be great.
The solution does come with few limitations which are documented.

[roblabla]

Awesome! The limitations shouldn't be a problem for me. I'll implement it in SunriseOS ASAP. Going over the docs, this stood out:

Specifing toolchain in the task or rustup_component_name in the install_crate structure, will make cargo-make ignore the min version value.

Maybe this should break the build, or at least put out a warning that min_version won't be respected?

Something I was wondering, but I'm not 100% sure if it's a good idea: can this be used to get cargo-make to self-update? If so, maybe it could get integrated with https://github.com/sagiegurari/cargo-make#usage-min-version ? Although something tells me such a feature would be annoying to implement on some platforms (Windows in particular).

[sagiegurari]

on windows the exe is locked while executing so ya, windows is out of the question.
however, self update is a cool idea. I'll open an issue regarding that.
as for the warn printing, I have a lot of it in case i'm unable to validate the min version, but nothing if i decide to skip it. it would make the code more... complex :( so I prefer to leave it out unless its really important.

if this and few other features I pushed in the previous days will look ok, I'll publish a new official version in few days.
self update would definitely not make it to this version.

[roblabla]

I'm running into a bit of a problem with this feature. I tried making a rule that updates cargo-xbuild, but when running it, I'm getting an error.

TOML:

[config]
skip_core_tasks = true
min_version = "0.21.0"

[tasks.install-cargo-xbuild]
install_crate = { crate_name = "cargo-xbuild", binary = "cargo", test_arg = ["xbuild", "--version"], min_version = "0.5.14" }

[tasks.bootstrap]
workspace = false
description = "Compiles the i386 bootstrap for debug"
dependencies = ["install-cargo-xbuild"]
command = "cargo"
args = ["xbuild", "--target=i386-unknown-none", "--package=sunrise-bootstrap" ]

Output:

[roblabla@roblab kfs]$ cargo make bootstrap --makefile Makefile.min.toml
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: Makefile.min.toml
[cargo-make] INFO - Task: bootstrap
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: install-cargo-xbuild
[cargo-make] ERROR - Missing cargo command to invoke.
[cargo-make] WARN - Build Failed.

EDIT: Is the binary/test_arg even necessary when specifying min_version? They don't seem to get deserialized at all - there's no field for them in the CargoPluginInfo. They are present in the example.

[sagiegurari]

InstallCrateInfo supports both min version + binary + test_arg so it should have used that.
but seems serde decided to deserialize with wrong type.
I fixed it and pushed to the dev branch so you can reinstall it and try it out.
thanks for testing.

[sagiegurari]

@roblabla did the latest fix resolve the issue?

[roblabla]

Tried it again, and there's still a bug. Here's a makefile:

[config]
skip_core_tasks = true

[tasks.install-cargo-xbuild]
install_crate = { crate_name = "cargo-xbuild", binary = "cargo", test_arg = ["xbuild", "--version"], min_version = "0.5.20" }

cargo make install-cargo-xbuild does not cause cargo-xbuild to get updated (which it should since cargo-xbuild version 0.5.20 isn't even released).

Did some digging, and I found that here, crate_only_info is false. This happens because I don't set a rustup_component_name. I think the check is inverted? If I invert the check, the rule properly updates cargo-xbuild.

[sagiegurari]

I'll setup more test cases for sure. thanks, will check

[sagiegurari]

fixed and added more tests

[sagiegurari]

@roblabla cargo make 0.22.0 has now been published with min version validation changes.