Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple aqua registries - Feature parity with Aqua #3364

Closed
dudicoco opened this issue Dec 5, 2024 · 27 comments
Closed

multiple aqua registries - Feature parity with Aqua #3364

dudicoco opened this issue Dec 5, 2024 · 27 comments

Comments

@dudicoco
Copy link

dudicoco commented Dec 5, 2024

Hi,

While trying to migrate to Mise from Aqua + Direnv, I've come across a few issues with features that exist in Aqua but not in Mise.

  • Support multiple registries: this is the most important feature that is missing. Within aqua.yaml you can define multiple registries including a local registry, so if you want to install a package that does not exist in the aqua standard registry you can define it locally: https://aquaproj.github.io/docs/develop-registry/#use-as-a-local-registry
  • aqua cp: this command allows you to copy the executable to a target directory, which makes installing packages in a multi-stage dockerfile easy: https://aquaproj.github.io/docs/guides/build-container-image/
  • aqua update-aqua: this command updates aqua to a different version. Unlike mise self-update, aqua update-aqua will keep multiple downloaded versions of aqua locally and symlink the one specified. This allows you to switch between different versions of aqua in different projects seamlessly without redownloading the binary every time.

Note: a better user experience here would be to automatically use the version of mise specified in mise.toml

  • Renovate updates: aqua allows updating the entire "toolchain" of aqua with renovate.
    • aqua version
    • aqua installer version
    • renovate extension version
    • aqua packages versions
    • aqua registry version
  • aqua g : fuzzy searches for packages and automatically adds them to the config file with the --install flag. Current workaround with mise - mise use --pin $(mise registry -b aqua | fzf --multi | awk '{print $2}').

Note: this workaround will also install the packages while aqua g -i only adds them to the config file. Nice to have but perhaps a flag could be added to decide if the package should be installed or just added to .mise.toml.

  • mise doesn't support pkg format:
INFO  aqua:aws/aws-cli@2.22.7   generate checksum AWSCLIV2-2.22.7.pkg
INFO  aqua:aws/aws-cli@2.22.7   extract AWSCLIV2-2.22.7.pkg
Error:
   0: failed to install aqua:aws/aws-cli@2.22.7
   1: unsupported format: pkg

Location:
   src/backend/aqua.rs:494

Version:
   2024.11.37 macos-arm64 (7ac5ab3 2024-11-30)
@jdx
Copy link
Owner

jdx commented Dec 5, 2024

Support multiple registries: this is the most important feature that is missing. Within aqua.yaml you can define multiple registries including a local registry, so if you want to install a package that does not exist in the aqua standard registry you can define it locally: https://aquaproj.github.io/docs/develop-registry/#use-as-a-local-registry

I think we should support this. Right now you can override the entire registry but we lack a way to provide multiple which would be useful.

aqua cp: this command allows you to copy the executable to a target directory, which makes installing packages in a multi-stage dockerfile easy: https://aquaproj.github.io/docs/guides/build-container-image/

I don't think this needs a dedicated command. You can do this like this already which I think is fine:

cp $(mise which node) /tmp/node

There is also an existing ticket for #1039 which is probably better for the multi-stage docker use-case anyhow.

aqua update-aqua: this command updates aqua to a different version. Unlike mise self-update, aqua update-aqua will keep multiple downloaded versions of aqua locally and symlink the one specified. This allows you to switch between different versions of aqua in different projects seamlessly without redownloading the binary every time.

I don't think I understand the value of being able to have different mise versions side-by-side. This is not how mise is designed and doing so is not only a lot of work but would involve a lot of future maintenance burden to keep that a supported use-case. I don't believe anyone has ever asked for the ability to run different versions of mise together, they just need a way to downgrade mise globally to prevent breaking changes or bugs when the occur.

Renovate updates: aqua allows updating the entire "toolchain" of aqua with renovate.

I don't use renovate with mise or maintain that integration. As I understand it renovate does support mise already but any requests for improvements there would likely need to go to them.

aqua g : fuzzy searches for packages and automatically adds them to the config file with the --install flag. Current workaround with mise - mise use --pin $(mise registry -b aqua | fzf --multi | awk '{print $2}').

this is mentioned on the roadmap

mise doesn't support pkg format:

this can be added, we already extract pkg files for installing swift so the logic just needs to be extended to aqua

Filter packages with tags: aqua allows you to add tags to packages and specify tags when installing packages.

I think MISE_ENV covers this use-case in a different way but one that seems to be sufficient since nobody has asked for this before I don't think.

@dudicoco
Copy link
Author

dudicoco commented Dec 5, 2024

I don't think I understand the value of being able to have different mise versions side-by-side. This is not how mise is designed and doing so is not only a lot of work but would involve a lot of future maintenance burden to keep that a supported use-case. I don't believe anyone has ever asked for the ability to run different versions of mise together, they just need a way to downgrade mise globally to prevent breaking changes or bugs when the occur.

I believe there is a big value in having a locked version of Mise in each repo, just like there is value in locking all of the packages that Mise installs.

For example, if you've intrduced a new feature in a new version and also deprecated an existing feature in the same release, now the new version cannot be used globally - if I have one project which needs the new feature and one project that needs the deprecated feature as it didn't migrate from it yet.
You could say that they have to align with each other but in reality different projects use different versions of tools and move in different paces (unless you're in a monorepo, which would be ideal :-) )

mise doesn't support pkg format:

this can be added, we already extract pkg files for installing swift so the logic just needs to be extended to aqua

Should I open a separate issue for this?

Filter packages with tags: aqua allows you to add tags to packages and specify tags when installing packages.

I think MISE_ENV covers this use-case in a different way but one that seems to be sufficient since nobody has asked for this before I don't think.

This is different than the tags feature. Aqua has a similar feature which allows you to split the config files: https://aquaproj.github.io/docs/guides/split-config/

The tags feature augments this as you can specify a tag across all files and choose to install only those packages,

@jdx
Copy link
Owner

jdx commented Dec 5, 2024

deprecated an existing feature in the same release

I don't believe I ever do this. Once a feature comes out of experimental it stays forever. If this ever were to be done it would involve a long migration path with warnings so that people have plenty of time to migrate without needing to have separate versions installed.

If you're talking about experimental features, well that comes with the territory. Wait until things become stable before relying on them.

The tags feature augments this as you can specify a tag across all files and choose to install only those packages,

The only use-case I can think of that tags would cover is you could use multiple envs, e.g.: MISE_ENV=ci,test which isn't supported today but we should add. I can't think of a use-case where tags would solve something MISE_ENV wouldn't.

@jdx
Copy link
Owner

jdx commented Dec 7, 2024

I added some of these, namely MISE_ENV=test,ci and pkg support for aqua. I think the only remaining thing we should pick up here is multiple aqua registries, which we should do, but I see that as lower priority and probably not trivial work. I'm going to update the title to reflect that.

@jdx jdx changed the title Feature parity with Aqua multiple aqua registries - Feature parity with Aqua Dec 7, 2024
@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

I have found more Aqua features which are missing from Mise:

  1. No support for all package types:
mise WARN  failed to resolve toolset: [~/repositories/package-managers/.mise.toml] aqua:alpkeskin/mosint@3.0.0: packages[0].typ
e: unknown variant `go_install`, expected one of `github_archive`, `github_content`, `github_release`, `http` at line 2 column 
11
  1. mise registry cannot find all packages in aqua registry, even when specifying a registry via aqua.registry_url = "https://github.com/aquaproj/aqua-registry" , for example aqua:iamhsa/pkenv cannot be found.

At this point I'm wondering if Mise should run the aqua binary directly instead of reimplementing all of its features.

@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

deprecated an existing feature in the same release

I don't believe I ever do this. Once a feature comes out of experimental it stays forever. If this ever were to be done it would involve a long migration path with warnings so that people have plenty of time to migrate without needing to have separate versions installed.

I can give some more examples:

  1. A bug in a new version which project a requires could break project b
  2. A regression in a new version which project a requires could affect project b

What is the downside of "officially" supporting different mise versions per project? The global config file? If that's the reason then it should be a non-issue since it should be backwards compatible

@jdx
Copy link
Owner

jdx commented Dec 8, 2024

What is the downside of "officially" supporting different mise versions per project?

it's a lot extra maintenance work to make sure mise is forwards and backwards compatible

@hverlin
Copy link
Contributor

hverlin commented Dec 8, 2024

I think you could probably achieve an isolated installation today by updating various environment variables as mentioned in #3306 (comment) and ignoring the global config file using ignored_config_paths without adding new features into mise. Probably, worth prototyping

@syhol
Copy link
Contributor

syhol commented Dec 8, 2024

More things you can do to manage separate installs:

You can use the tool 'ubi:jdx/mise' with a pinned version. I don't think it will change the mise used for hook-env or cd/enter/leave hooks but it will fix the version for any calls to mise. This might not be officially supported but it should work.

Instead of using 'ubi:jdx/mise' you could use mise.run:

  • curl https://mise.run | sh
  • MISE_INSTALL_PATH=/some/path – change the binary path (default: ~/.local/bin/mise)
  • MISE_VERSION=v2024.5.17 – install a specific version

As @hverlin mentioned you can change these https://mise.jdx.dev/directories.html#directory-structure values and https://mise.jdx.dev/configuration/settings.html#ignored_config_paths as you desire.

Also you have min_version https://mise.jdx.dev/configuration.html#minimum-mise-version

I'm curious if you need any more than this.

Personally min_version is enough for me, bugs are often fixed fast and I've not had any breaking changes that weren't hard to adapt to.

@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

Thanks all, i'll look into the suggested workarounds.

@jdx what are your thoughts on #3364 (comment)?

@jdx
Copy link
Owner

jdx commented Dec 8, 2024

I have found more Aqua features which are missing from Mise:

  1. No support for all package types:
mise WARN  failed to resolve toolset: [~/repositories/package-managers/.mise.toml] aqua:alpkeskin/mosint@3.0.0: packages[0].typ
e: unknown variant `go_install`, expected one of `github_archive`, `github_content`, `github_release`, `http` at line 2 column 
11

You should use the go backend for that. I don't want to add support for package types that require dependencies like go.

  1. mise registry cannot find all packages in aqua registry, even when specifying a registry via aqua.registry_url = "https://github.com/aquaproj/aqua-registry" , for example aqua:iamhsa/pkenv cannot be found.

Seems to work for me, unless this is something specific about overriding the registry_url:

~ ❯ mise x aqua:iamhsa/pkenv -- pkenv --version
mise aqua:iamhsa/pkenv@0.5.3      ✓ installed                                                                                  pkenv 0.5.3

At this point I'm wondering if Mise should run the aqua binary directly instead of reimplementing all of its features.

Who said I was reimplementing all of its features?

@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

  1. mise registry cannot find all packages in aqua registry, even when specifying a registry via aqua.registry_url = "https://github.com/aquaproj/aqua-registry" , for example aqua:iamhsa/pkenv cannot be found.

Seems to work for me, unless this is something specific about overriding the registry_url:

~ ❯ mise x aqua:iamhsa/pkenv -- pkenv --version
mise aqua:iamhsa/pkenv@0.5.3      ✓ installed                                                                                  pkenv 0.5.3

The problem is not with installing it, but with searching for it within the registry.

@jdx
Copy link
Owner

jdx commented Dec 8, 2024

oh I understand: the mise registry and the aqua registry are not the same thing. Perhaps confusing naming but I don't think we can do anything about that.

@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

@jdx doesn't mise bundle the aqua registry?

@jdx
Copy link
Owner

jdx commented Dec 8, 2024

yes but mise registry shows what's in the mise registry, not the aqua registry. Perhaps we could add a top-level mise aqua subcommand for these kind of things but I think it's pretty low priority. We've never had that sort of thing for the equivalent functionality in asdf and it's been fine. I also would be hesitant to add that since not everything in the aqua can be installed with mise. Almost no mise users will care about this since they're just going to use tools from the mise registry.

I think there is some confusion about why the aqua backend exists in mise. It's definitely not for users coming from aqua that just want to manage a similar setup through mise. It's mostly so we can leverage the standard aqua registry as a data source for giving mise a tighter supply chain. Just because you can do something in aqua doesn't mean you should be able to do so in mise. I'm not interested in duplicating functionality—if you want that just use aqua.

@dudicoco
Copy link
Author

dudicoco commented Dec 8, 2024

So each entry from the aqua registry is explicitly added to the mise registry and only then it can be searched for?
If so, then what is aqua.registry_url for? Tool installation only and not searching?
And why shouldn't we be able to search for tools which are installable by mise (such as iamhsa/pkenv)?

@jdx
Copy link
Owner

jdx commented Dec 8, 2024

It's a manual process to know if something can be installed/used via mise

@syhol
Copy link
Contributor

syhol commented Dec 8, 2024

So each entry from the aqua registry is explicitly added to the mise registry and only then it can be searched for?

Aqua is one of 9 backends (10 if you count core), and not all aqua tools are guaranteed to work in mise. Rather than trying to build a search feature for 10 different tools I personally think it makes more sense to just search the unified registry, and spend the effort getting more aqua tools into the mise registry.

Also some tools can't even be searched. Ubi has no index, it can be any github repo. asdf, vfox, and go have no index, it can be any git repo. And npm has over 3.1 million packages, so it might not make sense to maintain a local index for that.

You can also still install aqua for searching if you like. I install it with ubi.

That's just my take anyway.

@syhol
Copy link
Contributor

syhol commented Dec 16, 2024

#3570 has been added, so you can now search the registry on mise use. I don't think there are any more features in this issue that mise is considering supporting. We may be able to close this issue.

@jdx jdx closed this as not planned Won't fix, can't repro, duplicate, stale Dec 16, 2024
@dudicoco
Copy link
Author

@syhol @jdx what about the most significant feature - multiple registries?

@jdx
Copy link
Owner

jdx commented Dec 17, 2024

I think I'll pass on that for now

@syhol
Copy link
Contributor

syhol commented Dec 17, 2024

The project owner has spoken 😄

But out of curiosity, what is it you wanted out of the multiple registries?

Within aqua.yaml you can define multiple registries including a local registry, so if you want to install a package that does not exist in the aqua standard registry you can define it locally

If you want to be able to install packages that do not exist in the mise or aqua registries you have a ton of options:

  • you can use any of the backends directly npm:prettier, cargo:eza, ubi:cli/cli, aqua:1xzy/pryrite, etc. even when the tool isn't in the mise registry
  • you can (relatively) easily write your own asdf or vfox plugin to provide and install many things. A single plugin can also provide multiple tools.
  • in settings you can declare a shorthands_file to provide your own aliases much like how the mise registry does.
  • the mise link command let's you link custom built versions of any tool found in the registry.

Is there anything extra from a custom aqua registry that you are looking for?

@jdx
Copy link
Owner

jdx commented Dec 17, 2024

To be clear though, I'd certainly accept a PR. I think it's useful, but not enough to work on it myself.

@dudicoco
Copy link
Author

The project owner has spoken 😄

But out of curiosity, what is it you wanted out of the multiple registries?

Within aqua.yaml you can define multiple registries including a local registry, so if you want to install a package that does not exist in the aqua standard registry you can define it locally

If you want to be able to install packages that do not exist in the mise or aqua registries you have a ton of options:

  • you can use any of the backends directly npm:prettier, cargo:eza, ubi:cli/cli, aqua:1xzy/pryrite, etc. even when the tool isn't in the mise registry
  • you can (relatively) easily write your own asdf or vfox plugin to provide and install many things. A single plugin can also provide multiple tools.
  • in settings you can declare a shorthands_file to provide your own aliases much like how the mise registry does.
  • the mise link command let's you link custom built versions of any tool found in the registry.

Is there anything extra from a custom aqua registry that you are looking for?

I was using a local registry for packages that do not exist in the aqua registry.
I think ubi can cover this scenario in most cases.

@pd93
Copy link

pd93 commented Jan 24, 2025

I have found more Aqua features which are missing from Mise:

  1. No support for all package types:
mise WARN  failed to resolve toolset: [~/repositories/package-managers/.mise.toml] aqua:alpkeskin/mosint@3.0.0: packages[0].typ
e: unknown variant `go_install`, expected one of `github_archive`, `github_content`, `github_release`, `http` at line 2 column 
11

You should use the go backend for that. I don't want to add support for package types that require dependencies like go.

@jdx Just curious, I'm trying to add

[tools]
"aqua:eza-community/eza" = "latest"

to my mise config, but this comes back with mise ERROR [~/.config/mise/config.toml] aqua:eza-community/eza@latest: packages[0].version_overrides[0].type: unknown variant cargo, expected one of github_archive, github_content, github_release, http at line 10 column 15.

I'm absolutely fine with using the cargo backend for issues like this normally. However, looking at the registry.yaml file, it looks as though more recent versions of eza support the github_release package type and Mise is disregarding this. Would it be possible to support installing this while still ignoring versions which use compilers?

@jdx
Copy link
Owner

jdx commented Jan 24, 2025

I think you're on an old version of mise

@pd93
Copy link

pd93 commented Jan 24, 2025

Ah, I was on v2025.1.6. Updating to v2025.1.13 fixed it. Thanks for the speedy updates!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants