feat: Proof of concept: Use ubi as a library instead of as a binary

jdx / mise

dev tools, env vars, task runner

https://mise.jdx.dev

MIT License

8.03k stars 210 forks source link

feat: Proof of concept: Use ubi as a library instead of as a binary #2290

Open autarch opened 2 weeks ago

autarch commented 2 weeks ago

I took a stab at this using the library-ize branch of ubi. It seems to work from my testing locally, and the test suite also passed locally.

autarch commented 2 weeks ago

I honestly don't understand the internals of mise well enough to know if this PR is done or not.

jdx commented 2 weeks ago

it seems to be failing but it's unclear why:

E2E ./backend/test_ubi_token
  $ GITHUB_TOKEN=foobar mise install -f ubi:goreleaser/goreleaser@v1.25.0 2>&1
  Error: [GITHUB_TOKEN=foobar mise install -f ubi:goreleaser/goreleaser@v1.25.0 2>&1] command failed with status 1
  ./backend/test_ubi_token: 0s
  Error: exited with status code 1
  Test environment can be examined in /tmp/test_ubi_token.JQmoym
mise [test:coverage] exited with code 1
Error: Final attempt failed. Child_process exited with error code 1

autarch commented 2 weeks ago

it seems to be failing but it's unclear why:

E2E ./backend/test_ubi_token
  $ GITHUB_TOKEN=foobar mise install -f ubi:goreleaser/goreleaser@v1.25.0 2>&1
  Error: [GITHUB_TOKEN=foobar mise install -f ubi:goreleaser/goreleaser@v1.25.0 2>&1] command failed with status 1
  ./backend/test_ubi_token: 0s
  Error: exited with status code 1
  Test environment can be examined in /tmp/test_ubi_token.JQmoym
mise [test:coverage] exited with code 1
Error: Final attempt failed. Child_process exited with error code 1

This test replaces the ubi binary with a shell script that echoes back the GitHub token. It's testing that various env vars which contain a token are ultimately passed to ubi. I'm not sure exactly how to test this with ubi as a library.

autarch commented 2 weeks ago

Also, I think it'd be nice to add support for some other features, like telling ubi the executable name or telling it that the release it picks must match a certain string. The library-ized code supports this, but it's not clear how this would be done with mise. Would it make sense to add some additional ubi-specific flags, something like:

mise "ubi:houseabsolute/precious@v0.7.1" --ubi-matching musl --ubi-exe precious

The other options I can think of are:

Extend the syntax for packages that mise accepts to allow for more stuff. But that seems really gross and confusing. I don't think allowing per-backend extensions in that string would make for a nice UI.
Make mise look for env vars like UBI_MATCHING instead of flags. Personally, I think flags are better since they're self-documenting when you use clap. But on the flip side, adding lots of flags for each different backend could become quite unruly.

jdx commented 1 week ago

mise has support for tool config which should be documented more clearly:

[tools]
# send arbitrary options to the plugin, passed as:
# MISE_TOOL_OPTS__VENV=.venv
python = { version = '3.10', virtualenv = '.venv' }

which could be leveraged here. What's missing is a way to configure this on the command line in part because it's tricky to know how to be able to do that with multiple tools

autarch commented 1 week ago

mise has support for tool config which should be documented more clearly:
[tools]
# send arbitrary options to the plugin, passed as:
# MISE_TOOL_OPTS__VENV=.venv
python = { version = '3.10', virtualenv = '.venv' }
which could be leveraged here. What's missing is a way to configure this on the command line in part because it's tricky to know how to be able to do that with multiple tools

I pushed a commit that adds the ability to set "exe" and "matching" in the config file. I think it's ok if this is only available via the config file for now.