backend registry and asdf direct repo installs

[jdx]

I want to make it possible to do this:

$ mise use asdf:https://github.com/asdf-vm/asdf-nodejs

or:

$ mise use asdf:asdf-vm/asdf-nodejs

This likely doesn't have a ton of user-value (though I am sure some will want it), but it has major value for simplifying the mise codebase and indirectly this will make mise a lot simpler to use. What this would do is make it so you don't need to learn how to create a custom shorthand registry or anything, you would just specify the specific plugin repo if you want to change it.

This would allow us to get rid of the mise plugin registry and just have the code baked into the CLI. It also makes it possible to have different tools default to different backends, asdf would just be the most commonly used one, but otherwise it's "just another backend".

What we would instead have is just a map of shortnames -> backend:tool—potentially like this (just examples, don't freak out over the specific tools):

• ubi -> cargo:ubi
• node -> core:node
• elixir -> asdf:asdf-plugins/asdf-elixir
• ruby -> vfox:vfox-plugins/vfox-ruby

This makes asdf less "special" and would eliminate a ton of complexity in the code that has asdf logic in a mostly completely different code path than the rest of the backends. A shorthand like "ruby" would just be a pointer to <backend>:ruby. I see the shorthands as essentially just being the "preferred" backend for a given tool.

This is important for things like windows compatibility where asdf plugins won't work at all. Another thing it allows is us to progressively improve the mise ecosystem. For example, maybe initially the only way to install ubi might be with cargo:ubi but this has the downside of requiring the rust toolchain and slow compilation times. Maybe later we can change this to vfox:ubi or asdf:ubi once someone builds a plugin that provides precompiled binaries of ubi.

This way users only need to know mise use ubi@latest, but what that does under the hood may improve in future releases. There is a downside here that it may result in breaking changes if the shorthands change to something different. One solution to that may be having a lockfile.

Down the road I could see the ability to have some preferences around these. For example, maybe for some reason you prefer to fetch things with cargo over ubi because you don't have ubi installed. Maybe shorthands would point to a set of potential backends and mise would pick the most ideal one given your os/arch and what you have installed.

A non-goal would be this:

$ mise install asdf:nodejs

reason being is I want to get rid of maintaining a registry of only asdf shorthands and have a registry on top of all shorthands to backends.

[jdx]

actually I may have overthought the whole lockfile thing, I think future versions of mise should just put the full <backend>:<tool> into .mise.toml, e.g. if you run mise use elixir@1 it would create this config:

[tools]
"asdf:mise-plugins/mise-elixir" = "1"

That way your config would always use asdf even if mise later changed to vfox without needing a separate lockfile. Of course you could still manually put elixir = "1" into your .mise.toml if you prefer—but then the backend used may change when you upgrade mise. I think there are merits to having either full or short names in the config so users should be able to set their preference.

An important use-case we need to keep for backwards compatibility would be configs where "elixir" shorthands may use a different asdf plugin if it is installed.

Another concern I have is overriding with .mise.local.toml. If, say, .mise.toml defines "asdf:mise-plugins/mise-elxir" but .mise.local.toml defines a vfox plugin for elixir—mise should only install the vfox version and not the asdf one. I think we may need to introduce a concept like "provides" which in this case would be "elixir" so that this gets properly overridden. This is a problem today, but so far nobody has raised it and I only just now realized it myself.

[Adirelle]

This is indeed a good idea. If you are working on a project with a team and want to share the list of tools using the repository, something like "python" that resolves to either "core:python" or "asdf:asdf-community/asdf-python" depending on what has been locally installed can be counter-productive. Moreover, someone may want to use the former for a project and the latter for another one. Having an explicit value in the configuration would solve that.

[syhol]

I think the ability to use the full <backend>:<tool> is awesome, powerful and elegant, but it's not a great first experience with the tool and a lot of people first experience will be looking at a mise.toml file.

You start a new job, you're a real noobie, you see a file you've never seen before, which version sparks joy?

[tools]
"asdf:mise-plugins/mise-elixir" = "1.2.3"

or

[tools]
"elixir" = "1.2.3"

As @jatinn said:

[...] I need to mentally parse out the tool name
[...] I can imagine there being tools where it may not be obvious

So I would prefer the default remains the plain name rather than the full forge uri.

[jdx]

the way I'm thinking right now is it should match what the user types in, so if you put mise use elixir, that's what gets put in. If you put mise use asdf:mise-plugins/mise-elixir—that's what gets put in.

[jatinn]

If I understood this correctly the goal of this would be to no longer need https://github.com/mise-plugins/registry repo, is that correct?
If so, could something like the following work:

[tools]
go = 'latest'
exilir = '1'
ruby = '3'

[backends]
# there is a defined order: explicit overrides, mise core, mise community / vfox (if wanted), asdf core, asdf community, ...
# if still missing after searching from those then error out asking for the backend
# maybe have a `*` key so users can customize the backend search order
elixir = 'asdf:asdf-plugins/asdf-elixir'
ruby = 'vfox:vfox-plugins/vfox-ruby'

I used the backends key in the example but could we just reuse the plugins key instead?
There may likely some nuances/differences between backends and plugins that I am not be aware of but having ruby = 'https://github.com/asdf-vm/asdf-ruby' or ruby = 'asdf:asdf-vm/asdf-ruby' seems similar enough

[jdx]

yeah, something like that is what I'm thinking. This sort of covers some ground with the current [plugins] and [aliases] but it's different. I'd like to find something that could align them all if possible. I kind of like "aliases" personally but we'd need to figure out a compatible data model since the current implementation is just for versions, not tools themselves.

[jdx]

Perhaps, though there was another discussion where we went over the design of this and I actually wasn't sold on the current syntax, but since building it I think I like it, definitely more than having 2 separate keys. 2 keys would be a different way to get around the override problem though, so it's worth considering if that might be better than a "provides" internal key.

That said, it's still experimental so it's possible for us to change it if we want to.

[jatinn]

Actually I remembered that the hashicorp tools all have the same plugin https://github.com/asdf-community/asdf-hashicorp so if you needed just one of the tools how would that need to be specified?

[jdx]

"provides" isn't something the user would configure, it would be done by the plugin or in mise for popular plugins. It's something done in a lot of package managers like aur for example. It lets a plugin say what it "provides" like "python" for example. This would actually enable things we can't really do today like having dependencies of plugins where the dependency could be any plugin that happens to "provide" python.

[jdx]

Actually I remembered that the hashicorp tools all have the same plugin https://github.com/asdf-community/asdf-hashicorp so if you needed just one of the tools how would that need to be specified?

To me this isn't the most important functionality in general since it's not really used by anything other than hashicorp that popular—at least that I can think of off the top of my head. For backwards compatibility though we could just use a fake url parameter like asdf:asdf-community/asdf-hashicorp?name=terraform or have that be part of the config like "asdf:asdf-community/asdf-hashicorp" = {name = "terraform"}

We could also probably get hashicorp or fork their repo into plugins for their separate tools too.

[Adirelle]

It lets a plugin say what it "provides" like "python" for example.

The more the time passes, the more this looks like a dependency manager. Maybe this is inevitable.

[Adirelle]

This would actually enable things we can't really do today like having dependencies of plugins where the dependency could be any plugin that happens to "provide" python.

I am not sure that this is a goal but this could allow to split the current python core plugins into a "compile-python" plugin and a "install-standalone-python" plugin. Both would provide "python". Note that this would raise a new question: what happens when several plugins provides the same thing?