jdx / mise

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

create cargo-binstall plugin #2062

Open jdx opened 6 months ago

jdx commented 6 months 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 6 months 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 6 months ago

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

Adirelle commented 6 months 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 6 months 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 6 months 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 5 months 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 5 months 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 5 months 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.

jimeh commented 3 months ago

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

autarch commented 3 months ago

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.