jdx / mise

dev tools, env vars, task runner
https://mise.jdx.dev
MIT License
8.11k stars 214 forks source link

create cargo-binstall plugin #2062

Open jdx opened 1 month ago

jdx commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Adirelle commented 1 month ago

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 commented 1 month ago

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

jimeh commented 1 month ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 3 weeks ago

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.