create cargo-binstall plugin

[jdx]

might be ideal to wait for vfox for this. If we had this, it would be possible to make bootstrapping a lot faster when using the cargo backend, e.g.:

[tools]
cargo-binstall = "latest"
"cargo:eza" = "latest"

[Adirelle]

It seems that the cargo backend already uses cargo-binstall when it is available (https://github.com/jdx/mise/blob/main/src/forge/cargo.rs#L66).

[jdx]

yes but there isn't a fast way to install cargo-binstall to use it

[Adirelle]

Ah, I see. This is the same problem for all these backends. I do not know how mise handle these dependencies. There is the ordering, but also the update of the environment.

For example with the pipx backend : the pipx backend depends on pipx being installed, and pipx depends on python being installed, so if mise had to install python, pipx and then pipx:mkdocs in one run, it should follow these steps:

1. install python,
2. with an environment updated from step 1, install pipx,
3. with an environment updated from step 2, install mkdocs using pipx.

This is easy to do if you activate mise and execute three separate commands in the shell, but can mise do this internally?

[jdx]

yes, it has logic to handle this use-case, however the dependencies currently need to be manually defined in the mise cli

[jimeh]

I was thinking along the same lines about about the UBI backend. Could cargo-binstall and/or UBI be pulled into mise as Rust libraries, so there's no need to install them separately?

I'm not sure if either of those projects actually exposes usable library crates, or if they'd even be open to such suggestions. I'm just throwing my two cents out :)

[autarch]

I was thinking along the same lines about about the UBI backend. Could cargo-binstall and/or UBI be pulled into mise as Rust libraries, so there's no need to install them separately?

I'm not sure if either of those projects actually exposes usable library crates, or if they'd even be open to such suggestions. I'm just throwing my two cents out :)

I'm the author of ubi. I'd be open to this. We'd just have to hammer out the details of what the API should look like.

[autarch]

Actually, looking at the ubi code right now, I think this would be quite easy. It's already split so that there's a main.rs that creates a Ubi struct from the CLI args. That struct has just a couple crate-public methods. I think making those methods fully public would be sufficient.

[autarch]

I took a stab at making ubi a library here - https://github.com/houseabsolute/ubi/tree/library-ize

I think this could probably be used by mise as-is. I would note that it lazily just returns anyhow::Result everywhere instead defining its own error types using something like thiserror. But I don't know how useful error types would be, since basically all the errors are fatal and probably require some sort of user intervention.

[jimeh]

@jdx had any chance to think about embedding ubi / cargo-binstall as rust dependencies? :)

[autarch]

I have a mostly done PoC PR of ubi-as-a-library in #2290. There's a test failing that I'm sure not sure how to replace, since it relies on mocking the ubi binary. Other than that, it seems to work fine.

FWIW, I think ubi does everything that cargo-binstall does, at least with GitHub. And it works with projects in any language, as long as there's a single-file binary to install.