Closed achou11 closed 5 months ago
Seems like the plugins in question are now reporting the expected latest versions. Will close for now but may re-open in the future if I notice similar "delay" :)
The same issue is happening right now with Julia and version 1.10.4 (released yesterday). This version doesn't show up in the mise ls-remote julia
output, nor does it appear in the cache. Clearning the cache doesn't help. Running the list-all
script in the julia plugin does list the 1.10.4 version correctly.
mise doctor
output
version: 2024.6.1 linux-x64 (6a3f377 2024-06-03)
activated: yes
shims_on_path: no
build_info:
Target: x86_64-unknown-linux-gnu
Features: DEFAULT, NATIVE_TLS, OPENSSL
Built: Mon, 3 Jun 2024 22:26:16 +0000
Rust Version: rustc 1.78.0 (9b00956e5 2024-04-29)
Profile: release
shell:
/bin/zsh
zsh 5.9 (x86_64-debian-linux-gnu)
dirs:
data: ~/.local/share/mise
config: ~/.config/mise
cache: ~/.cache/mise
state: ~/.local/state/mise
shims: ~/.local/share/mise/shims
config_files:
~/.config/mise/config.toml
backends:
cargo
core
go
npm
pipx
spm
ubi
plugins:
bun (core)
cmake https://github.com/srivathsanmurali/asdf-cmake.git#3811ad7
deno (core)
elixir https://github.com/asdf-vm/asdf-elixir.git#a4c42e1
erlang (core)
eza https://github.com/lwiechec/asdf-eza.git#08c1b65
fd https://gitlab.com/wt0f/asdf-fd.git#17d56e0
fzf https://github.com/kompiro/asdf-fzf.git#d19eb67
go (core)
java (core)
julia https://github.com/rkyleg/asdf-julia.git#97cf19a
node (core)
python (core)
rebar https://github.com/Stratus3D/asdf-rebar.git#4af0770
ripgrep https://gitlab.com/wt0f/asdf-ripgrep.git#e836665
ruby (core)
starship https://github.com/grimoh/asdf-starship.git#9ffad1c
usage https://github.com/jdx/mise-usage.git#fe3888a
vale https://github.com/pdemagny/asdf-vale#9926c81
vhs https://github.com/chessmango/asdf-vhs.git#8c1d33e
zig (core)
toolset:
cargo:mdcat@2.1.2
cargo:ouch@0.5.1
go:github.com/brimdata/zed/cmd/zq@1.15.0
go:github.com/tomnomnom/gron@0.7.1
cmake@3.24.1
elixir@1.16.0-otp-25
erlang@25.0
erlang@23.2.1
eza@0.18.16
fd@10.1.0
fzf@0.52.1
go@1.22.3
java@22.0.1
julia@1.10.3
julia@1.8.5
julia@1.7.3
julia@1.6.7
node@21.7.3
python@3.12.3
rebar@3.20.0
rebar@3.16.1
ripgrep@14.1.0
ruby@3.3.2
starship@1.19.0
usage@0.3.0
vale@3.4.2
vhs@0.3.0
env_vars:
MISE_SHELL=zsh
settings:
activate_aggressive = false
all_compile = false
always_keep_download = false
always_keep_install = false
asdf_compat = false
cargo_binstall = true
color = true
disable_default_shorthands = false
disable_tools = []
experimental = true
go_default_packages_file = "~/.default-go-packages"
go_download_mirror = "https://dl.google.com/go"
go_repo = "https://github.com/golang/go"
go_set_gopath = false
go_set_goroot = true
go_skip_checksum = false
http_timeout = 30
jobs = 4
legacy_version_file = true
legacy_version_file_disable_tools = []
node_compile = false
not_found_auto_install = false
paranoid = false
plugin_autoupdate_last_check_duration = "7d"
python_default_packages_file = "/home/david/.default-python-packages"
python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
raw = false
trusted_config_paths = ["~/CI"]
quiet = false
verbose = false
yes = false
ci = false
debug = false
trace = false
log_level = "info"
python_venv_auto_create = false
[status]
missing_tools = "if_other_versions_installed"
show_env = false
show_tools = false
No warnings found
No problems found
Describe the bug
Very recently, running
mise ls-remote <PLUGIN>
is not returning the latest available valid version despite me knowing that there's one available. This affects things likemise upgrade
andmise outdated
.Using mise's deno plugin as an example where I see this right now. I currently have
v1.42.3
installed (my requested version islatest
) and I'm trying to upgrade tov1.42.4
. I usually just domise upgrade
and everything works as expected. When it stopped working, I suspected thatls-remote
wasn't providing the expected information, so my assumption is that the underlying implementation could be the root cause.To Reproduce
I noticed the page about mise's cache behavior, so I cleared it before trying these reproduction steps:
mise cache clear deno
mise ls-remote deno
. shows1.42.3
as the latest versionI inspected the msgpack file as described in the cache docs, and it also returned
1.42.3
as the latest.Expected behavior
It finds the latest version (which is within my valid range) and lists it.
mise doctor
outputAdditional context
I've noticed this issue for a few plugins I use. Some are core mise ones but the others are asdf ones. I suspected that reporting the issue for asdf ones might not be helpful because mise just uses the implementation of the plugin, which may have issues unrelated to mise.
I also took a look at the underlying implementation of the deno plugin and visited the github url that's used to fetch the releases: https://api.github.com/repos/denoland/deno/releases. At the time of writing, v1.42.4 is listed as the most recent one, which is what I would expect! This led me to believe that there may be an issue in mise, but could be mistaken.