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

Latest fails to install latest version when another version is installed #2084

Open
Adirelle opened this issue May 13, 2024 · 10 comments
Open
Labels
bug Something isn't working

Comments

@Adirelle
Copy link
Contributor

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

  1. Install or use a tool with a fixed version.
  2. Try to install or use the same tool with the @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

@Adirelle Adirelle added the bug Something isn't working label May 13, 2024
@jdx
Copy link
Owner

jdx commented May 13, 2024

it's possible #2083 may fix this, I fixed a few things around "latest" versions

@Adirelle
Copy link
Contributor Author

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.

@jdx
Copy link
Owner

jdx commented May 13, 2024

actually scratch that, this is expected behavior with mise x. mise i will use the latest version but mise x will use the "latest" version that is currently installed. It does not automatically fetch a version unless it's one that doesn't match any current ones.

@jdx
Copy link
Owner

jdx commented May 13, 2024

e.g.: anytime you install something mise creates a symlink like ~/.local/share/mise/dummy/latest that points to the latest installed version, it has nothing to do with whatever the latest available version is—in part because that version will change

@jdx
Copy link
Owner

jdx commented May 13, 2024

the purpose here is to avoid unnecessarily fetching runtimes, updating is explicit with commands like mise install or mise upgrade

@Adirelle
Copy link
Contributor Author

Oh... I see. Maybe that should be documented (or stressed out if it it already) because this a bit counter-intuitive.
Does "use" follow the same rule?

@jdx
Copy link
Owner

jdx commented May 13, 2024

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 mise use, mise upgrade, and mise install which set a "latest_versions" flag which internally changes the resolver to ignore matching installed versions and instead use the latest available versions. Every other command defaults to just using what is on disk. Similarly, there is logic around missing versions that is even more complex but essentially mise will autoinstall missing versions if it has no matching version and you've already installed at least one version of the same tool. The use-case this captures is when someone uses a project that defines particular tools they don't want to manage by mise and some they do. In a way this supports legacy behavior from asdf because that's how it behaved and I wanted mise to be largely similar, but I also think it's a good middle ground where you get to be explicit about what tools you want mise to manage without it making assumptions about your setup.

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 mise x, mise run, and mise use and once they understand those 3 commands they wouldn't need to read any more documentation.

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.

@Adirelle
Copy link
Contributor Author

Adirelle commented May 13, 2024

I think there are several options there:

  • a squelch-able warning (opt-out) when using an outdated "latest":
Warning: a new version of tool SOMETOOL is available. 
Upgrade with "mise upgrade SOMETOOL" or disable this warning with "mise settings warnings.outdated_latest false"
  • an option to always upgrade to the latest version of a tool (opt-in) :
mise settings upgrade_latest always

@jdx
Copy link
Owner

jdx commented May 13, 2024

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.

@Adirelle
Copy link
Contributor Author

The idea was to let the user chose, ultimately, but maybe this should not be a global configuration but a command flag, e.g. mise exec --upgrade sometool@latest -- sometool something something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants