mise use latest does not actually install the latest versions of tools

[nickchomey]

Describe the bug A clear and concise description of what the bug is. I just started using mise. When I run mise use -g go or mise use -g go@latest, it installs 1.22.3, while 1.22.4 is the latest. If I specify go@1.22.4, it successfully downloads. Then mise prune works to remove 1.22.3, and mise use -g go then changes it to go = "latest" in confg.toml

The same thing happens with

• bun - installs 1.1.10 rather than 1.1.12
• deno - 1.44.0 rather than 1.44.1
• python - 3.12.3 rather than 3.12.4

I can update bun to the latest manually and then mise recognizes it as latest (following the same procedure as go). But deno and python just fail. I assume python is because it looks for a standalone build that doesnt yet exist, not sure about deno.

I'm sure there's a perfectly reasonable explanation for this. But is there something that can be done to resolve it?

[nickchomey]

I also just saw this - mise list thinks the new, manually installed versions are outdated. But mise outdated and mise prune do not - they appropriately list and remove the old ones once the new one is installed.

[alock]

I encountered the same issue with the core go plugin. For me that was the only one I'm using so I just moved away from the core plugin and am using the asdf one with mise plugins install go https://github.com/asdf-community/asdf-golang. Seems like that one doesn't have an issue.

[nickchomey]

I didnt realize we could use asdf plugins. Using asdf-deno solves the version issue i reported in the OP. There doesn't seem to be an asdf-bun though, and asdf-python just breaks.

Regardless, I hope that this can get fixed natively in mise so we don't have to go through the extra step

[mkblast]

Same issue here. also happens when using asdf-zig. can't find 0.13.0 until i specify it.

[shirayu]

This should be related to #2265

[nickchomey]

Ok, I think I've figured this out.

The FAQ addresses this issue

There are 2 places that versions are cached so a brand new release might not appear right away.

The first is that the mise CLI caches versions for 24 hours. This can be cleared with mise cache clear.

The second uses the mise-versions.jdx.dev host as a centralized place to list all of the versions of most plugins. This is intended to speed up mise and also get around GitHub rate limits when querying for new versions. Check that repo for your plugin to see if it has an updated version. This service can be disabled by setting MISE_USE_VERSIONS_HOST=0.

If you run mise set MISE_USE_VERSIONS_HOST=false, then it seems to install the latest version - but with a few seconds delay. This delay also seems to happen on other commands like mise outdated etc..

So, the question is - is there anything that can be done to refresh the mise-version repo more frequently so that we can benefit from its caching, but also get the latest versions?

The problem also might stem from the fact that https://mise-versions.jdx.dev redirects to https://github.com/jdx/mise-versions/, which doesn't even exist... It disappeared somewhere between January and March 2024 https://web.archive.org/web/20240106202946/https://github.com/jdx/mise-versions/

edit: no, that's not the issue (though might be part of the issue) because bun 1.1.10 (the version in mise's cache) was released 2 weeks ago

Yet, this function is quite clearly what is fetching the versions, it and points to those non-existent URLs

[jdx]

some jobs are failing, but https://github.com/jdx/mise/issues/2267 is actually the root cause so should be fixed soon

[nickchomey]

I'm not so sure that #2267 is the root cause - I have a ~/.local/share/mise/plugins directory. It must be due to the failing jobs - is there related code that we could inspect and help with?

And, as mentioned in my edit to my previous comment - the Mise codebase and docs are full of references to the now-non-existent https://mise-versions.jdx.dev/ and https://github.com/jdx/mise-versions/. Could that be related? Should those references be updated?

[jdx]

the repo is private

[mkblast]

I think the issue if fixed now.