Open reitzig opened 5 months ago
🛎️ @jdx FYI
Thank you for your report. I could reproduce the issue.
ubuntu@f84426d0dfb5:~$ ls -lh "$(which node)"
lrwxrwxrwx 1 ubuntu ubuntu 48 Jun 5 20:06 /home/ubuntu/.local/share/mise/shims/node -> /home/ubuntu/.local/share/aquaproj-aqua/bin/mise
ubuntu@f84426d0dfb5:~$ ls -lh /home/ubuntu/.local/share/aquaproj-aqua/bin/mise
lrwxrwxrwx 1 ubuntu ubuntu 13 Jun 5 20:06 /home/ubuntu/.local/share/aquaproj-aqua/bin/mise -> ../aqua-proxy
node - (link) -> mise - (link) -> aqua-proxy
aqua-proxy - (execute) -> `aqua exec node` -> `aqua exec node` fails because `node` isn't managed by aqua
When node --version
is executed, node
is a symbolic link to mise, and mise is a symbolic link to aqua-proxy.
aqua-proxy executes aqua exec node
but it fails because node
isn't managed by aqua.
I'm not sure why I didn't notice this issue, but I don't come up with the idea to resolve this issue at the moment.
I'm not familiar with mise, but as you said mise activate
can be a workaround for some usecases.
I think I might suggest in this case using mise activate
or mise x <...etc>
I don't think it's a good idea for manual use to mise via aqua. For programmatic use cases I can imagine this could make sense as a way to acquire mise, but I think a programmatic use case will benefit from a more explicit executions. Note that an aqua-installed mise will be a version-pinned mise, but that won't also pin exact versions of 3rd-party plugins.
I'd suggest that aqua and mise bring different approaches to versioning, and that both are fantastic tools, but best at slightly different jobs. Mixing them will get into some advanced/nuanced territory. There are some use cases for this, and each will have tools or languages that the other may have difficulty integrating for one reason or another, but just know that it could get weird
For local/user/system-wide use (meaning: for most things other than source-controlled projects), I'd recommend installing mise separately and using its own update systems.
I tend to agree: installing mise through aqua (or vice-versa) seems to make little sense. So, should mise be removed from aqua-registry?
There are two options.
The option 1 is simple but a breaking change, so this needs a major update of aqua-registry. We can apply the option 2 in other use cases and don't need a major update, but we need to add the feature to aqua.
Same as mise
, there are some packages aqua can't support well.
I'd recommend a warning, and recommend not removing mise. I'm speaking as an advisory member of mise and a fan of both mise and aqua, but as best I can without any bias and just purely from what I think is a good path forward.
There is software that mise can help acquire that will be challenging for aqua. One example is software that has a hard requirement on setup/installation steps after fetching artifacts (may require root, may need to launch daemons, etc). That's not saying everyone should move to mise only, aqua's approach offers more guarantees on how software is versioned and how it's being acquired, and generally will require less community plugins.
Anyway I do want to re-state that using a combination of mise and aqua where one is installed using the other is going to be advanced, and best suited to very specific programmatic use cases. Some things will not be supportable (like double-shims) at all for technical limitations beyond what either tool is attempting to solve. If anyone uses both locally (I do!) then I recommend installing them separately and not using one to install the other.
For an installation warning, let me suggest this as a starting place:
WARNING: Some functionality of mise is known to be degraded when installed via aqua and cannot be supported. For most use-cases, we recommend to install mise separately. For more details see https://github.com/aquaproj/aqua-registry/issues/23642
package name
aqua version
Environment
Overview
Chaining shims doesn't work: While it's possible to install tools through mise, their shims "forward" to the aqua shim/proxy, which can not resolve the foreign command names.
How to reproduce
Dockerfile
Expected Behaviour
Output:
Actual Behaviour
Output:
Important factoids
In the above setting, we (correctly) get:
ref: mise.jdx.dev/getting-started > 2b. Alternative: Add mise shims to PATH
Activating mise works:
ref: mise.jdx.dev/getting-started.html > Activate mise
But: Shims are necessary for integrating with non-CLI tools such as IDEs.
ref: mise.jdx.dev/ide-integration
References