Installing multiple tools from one repo with ubi

[arlyon]

Hi!

I like using mise+ubi and wanted to try out a tool called fluvio. They have a handful of clis all available in the same repo which I'd like to add using ubi, however since all the binaries come from the same repo, the keys clash.

I would like to suggest adding an additional syntax item to the key name that could be used by plugins for whatever they'd like to disambiguate. In the case of the ubi plugin, whatever is in the #suffix could be mapped to the matching key in the associated value.

[tools]
rust = "1.82.0"
- "ubi:infinyon/fluvio" = { version = "v0.12.0", matching = "fluvio" }
- "ubi:infinyon/fluvio" = { version = "v0.12.0", matching = "cdk" }
+ "ubi:infinyon/fluvio#fluvio" = { version = "v0.12.0" }
+ "ubi:infinyon/fluvio#cdk" = { version = "v0.12.0" }

[jdx]

I think you might be able to do this with mise use ubi:infinyon/fluvio[matching=fluvio] but I haven't tested. If it doesn't work, try putting that into the config file as it might just be an issue with mise use

[fiadliel]

This is more than a file syntax issue; you can put two references to the same ubi package in different mise projects but with different downloaded binaries. Only one of these will work, as the other will believe the package is already downloaded and correctly installed.

e.g. project 1 has mise.toml:

[tools]
"ubi:infinyon/fluvio" = { version = "v0.12.0", matching = "fluvio" }

project 2 has mise.toml

[tools]
"ubi:infinyon/fluvio" = { version = "v0.12.0", exe = "cdk" }

Even though there's no issue with a config file key conflict, they do clash in the cache directory. The settings of whichever instance is installed first, is the one used.

This does work for me, if the exe and matching is encoded into the package name as suggested above; the tooling configuration is then also encoded into the cache file, e.g.

$ which fluvio
.../.local/share/mise/installs/ubi-infinyon-fluvio-matching-fluvio/0.12.1/bin/fluvio

I think these settings should always be encoded into the cache name.

[jdx]

I see, this is tricky. I don't think it's a great idea to start adding the options onto the name. The name of the install is supposed to be part of the UX and appending a bunch of crap doesn't seem very usable—especially considering options might contain a ton of information.

That said, I don't know what a good alternative might be. #2885 would be a bandaid for this, but it would require some custom config just to make this work correctly.

[fiadliel]

I don't think it's a great idea to start adding the options onto the name.

What I meant was to add the options to the path to the cached files somehow (hash? sub-path? encode into an existing path component)? I wouldn't like this to be present in the UX unless you look at where the files are stored - I agree it's not friendly to have there.

The alias option mentioned in #2885 does workaround it slightly - but my main issue with this is that a defensive encoding of the mise config, with a scenario like above, would need to use aliases just in case another project requests a different binary in the same repo. And as mise usage expands in the ecosystem, the chances of this happening increase.

[jdx]

I wouldn't like this to be present in the UX unless you look at where the files are stored

the file structure is the UX. I intend for users to interact directly with the mise install directories.

[pdecat]

This UBI issue houseabsolute/ubi#68 may help if implemented.

[jdx]

I think the solution here is to use aqua