-
Notifications
You must be signed in to change notification settings - Fork 290
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
Latest fails to install latest version when another version is installed #2084
Comments
it's possible #2083 may fix this, I fixed a few things around "latest" versions |
Not yet >>> E2E plugins/test_version_latest
$ mise ls dummy
[mise ls dummy] output is equal to ''
$ mise x dummy@latest -- dummy
mise dummy@2.0.0 ✓ installed
[mise x dummy@latest -- dummy] '2.0.0' is in output
$ mise ls dummy
[mise ls dummy] '2.0.0' is in output
mise dummy@2.0.0 ✓ uninstalled
$ mise ls dummy
[mise ls dummy] '2.0.0' is not in output
$ mise x dummy@1.0.0 -- dummy
mise dummy@1.0.0 ✓ installed
[mise x dummy@1.0.0 -- dummy] '1.0.0' is in output
$ mise ls dummy
[mise ls dummy] '1.0.0' is in output
$ mise x dummy@latest -- dummy
E2E assertion failed: [mise x dummy@latest -- dummy] expected '2.0.0' to be in 'This is Dummy 1.0.0!' Would you like to push that test as a PR? I am not sure I will be able to fix it though. |
actually scratch that, this is expected behavior with |
e.g.: anytime you install something mise creates a symlink like |
the purpose here is to avoid unnecessarily fetching runtimes, updating is explicit with commands like |
Oh... I see. Maybe that should be documented (or stressed out if it it already) because this a bit counter-intuitive. |
I think it is mostly intuitive—otherwise calling a shim would automatically install the latest version every time you call it which would be more strange. This could probably be documented, though it would take careful reading of the code here since there are a ton of edge cases around how versions get resolved that I'm continually tweaking to find the right UX. Right now I think the logic generally behaves the way users expect—save for a handful of quirks like #2033. Unfortunately my tweaks have resulted in logic that is not easy to explain. It errs on the side of what I think the user will most benefit from rather than what is most predictable or easy to understand. I think there is a real risk trying to spell this out because I don't think it would capture all the details or be likely to stay current. Instead, I'll just explain it in this issue since that makes it clear this isn't an evergreen document I need to keep up to date. The logic right now is (from my memory, which may be slightly off) that there is a set of commands such as In any case, that's the general behavior today, but as I said, I tweak this stuff fairly regularly as I come up with ideas on how to balance mise such that it behaves in a way that's easy to use, does what you expect, doesn't get in your way, and behaves predictably—in that order. I prefer mise to make educated guesses even if they might not seem obvious because it makes the tool easy to use without reading documentation. My ultimate plan is that users would really only need to know I thought about this issue a bit and that maybe we shouldn't create the "latest" symlink if we know the version being installed isn't the latest version. However that would not be easy to do, likely to cause significant bugs, and I think will actually result in some even stranger behavior after I thought it through a bit. I also think it probably would break some workflows especially around the partial symlinks like "2" and "2.0". I think it's better to always have those symlinks there, rather than based on what the latest available versions are. Maybe if I was starting from scratch but it's far too risky to consider doing something like this now. |
I think there are several options there:
mise settings upgrade_latest always |
I really don't think this is a warning-level issue. If, say, a new version comes out there is no reason to warn the user about that. A setting could be made to autoinstall the latest versions but I think that might prove to be more annoying than you think. Tools can take several minutes to compile which would completely block you from using them if you had this enabled. |
The idea was to let the user chose, ultimately, but maybe this should not be a global configuration but a command flag, e.g. |
Describe the bug
When any version of a tool was already installed by mise, using
@latest
selects that version instead of the latest one available from remote.To Reproduce
@latest
version.Expected behavior
The second step should install and run the latest version to the tool according to the remote repository.
Additional context
Here is a E2E test that demonstrates the issue with the dummy plugin : https://github.com/Adirelle/mise/blob/0855ae29044184a7d16eb88011e79e6dda4571c8/e2e/plugins/test_version_latest
The text was updated successfully, but these errors were encountered: