tag_regex in ubi backend becomes ineffective after install

[Yasushi]

Description

After installing a package using ubi backend with tag_regex, subsequent ls-remote commands show unfiltered tags that should have been filtered out by the regex.

Steps to Reproduce

1. Clear the cache and check available versions (works as expected):

% mise cache clear
mise cache cleared
% mise ls-remote 'ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]' | tail -n 3
1.10.20
1.10.21
1.10.22

2. Install the latest version:

% mise install 'ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]@latest'
mise Installed executable into /Users/yasushi/.local/share/mise/installs/ubi-cargo-bins-cargo-binstall/1.10.22/cargo-binstall
mise ubi:cargo-bins/[email protected] ✓ installed

3. Clear cache and check versions again (tag_regex no longer works):

% mise cache clear
mise cache cleared
% mise ls-remote 'ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]' | tail -n 5
detect-targets-v0.1.38
detect-wasi-v1.0.20
1.10.20
1.10.21
1.10.22

4. Workaround - removing the installation directory restores the filter:

% rm -r ~/.local/share/mise/installs/ubi-cargo-bins-cargo-binstall
% mise cache clear
mise cache cleared
% mise ls-remote 'ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]' | tail -n 5
1.10.20
1.10.21
1.10.22

Current Behavior

After installing a package, the tag_regex filter in the ubi backend stops working, showing all tags including those that should be filtered out (e.g., detect-targets-v0.1.38).

Expected Behavior

The tag_regex filter should continue to work after installation, showing only tags that match the specified regex pattern (^\d+\.).

Workaround

Removing the installation directory (~/.local/share/mise/installs/ubi-cargo-bins-cargo-binstall) and clearing the cache restores the proper tag_regex filtering behavior.

Environment

• mise version: 2025.1.15 macos-arm64 (2025-01-26)

[jdx]

I think this is an XY problem. What is it you're ultimately trying to accomplish? It looks like you want to use cargo-bins to install things but I actually don't think mise will ever be able to use that effectively. The project has too many tags for mise to ever work well with it.

[Yasushi]

Let me clarify the actual issue I'm concerned about.

According to the mise documentation about ubi:

What sometimes happens is vendors will have GitHub releases for unrelated things. For example, cargo-bins/cargo-binstall is the repo for cargo-binstall, however it has a bunch of releases for unrelated CLIs that are not cargo-binstall. We need to filter these out and that can be specified with the tag_regex tool option.

I've noticed that this filtering mechanism appears to break in certain scenarios. Here's a concrete example with jib that demonstrates the issue:

1. Initial setup works as expected:

% mise use 'ubi:GoogleContainerTools/jib[tag_regex=-cli,extract_all=true]@0.10.0-cli'
mise Installed contents of archive file into /Users/yasushi/.local/share/mise/installs/ubi-google-container-tools-jib/0.10.0-cli
mise ubi:GoogleContainerTools/[email protected] ✓ installed
mise ~/xxx/mise.toml tools: ubi:GoogleContainerTools/[email protected]

2. This creates a mise.toml with the correct configuration:

[tools]
"ubi:GoogleContainerTools/jib" = { version = "0.10.0-cli", extract_all = "true", tag_regex = "-cli" }

3. When changing to 'latest' version:

% sed -i.bak  -e 's/0.10.0-cli/latest/' mise.toml
% cat mise.toml
[tools]
"ubi:GoogleContainerTools/jib" = { version = "latest", extract_all = "true", tag_regex = "-cli" }

4. The mise outdated command suggests an incorrect version:

% mise cache clear
mise cache cleared
% mise outdated
name                          requested  current     latest      source
ubi:GoogleContainerTools/jib  latest     0.10.0-cli  3.4.4-maven ~/xxx/mise.toml

The issue is that when using latest, mise seems to ignore the tag_regex filter and suggests 3.4.4-maven as the latest version, which doesn't match our -cli tag filter. This could lead to unexpected version upgrades when using mise upgrade.

Is this the intended behavior? Should latest respect the tag_regex filter?

[jdx]

certainly seems like a bug, looking at

mise/src/backend/ubi.rs

Lines 36 to 68 in f342d0a

	fn _list_remote_versions(&self) -> eyre::Result<Vec<String>> {
	if name_is_url(&self.tool_name()) {
	Ok(vec!["latest".to_string()])
	} else {
	let opts = self.ba.opts();
	let tag_regex = OnceLock::new();
	let mut versions = github::list_releases(&self.tool_name())?
	.into_iter()
	.map(|r| r.tag_name)
	.collect::<Vec<String>>();
	if versions.is_empty() {
	versions = github::list_tags(&self.tool_name())?.into_iter().collect();
	}
	Ok(versions
	.into_iter()
	// trim 'v' prefixes if they exist
	.map(|t| match regex!(r"^v[0-9]").is_match(&t) {
	true => t[1..].to_string(),
	false => t,
	})
	.sorted_by_cached_key(|v| !regex!(r"^[0-9]").is_match(v))
	.filter(|v| {
	if let Some(re) = opts.get("tag_regex") {
	let re = tag_regex.get_or_init(|| Regex::new(re).unwrap());
	re.is_match(v)
	} else {
	true
	}
	})
	.rev()
	.collect())
	}
	}

it's not clear to me why this would happen unless it's caching if you at one point didn't use that tag_regex on that tool. That's my guess at least since I think it is not taking tag_regex into account for the cache. I believe we do this for python here:

mise/src/plugins/core/python.rs

Line 467 in f342d0a

.with_cache_key((SETTINGS.python.compile == Some(false)).to_string())

So if I'm correct we would need to add tag_regex as part of the cache key like with python, but this is tricky since it seems that method doesn't take in the tool arg. I'm not sure if we could add that as an argument to that or not.

One idea I just had around this is that instead of tag_regex maybe we could have a tag_regex_extract or something that would be like tag_regex_extract=(\d+\.\d+\.\d+)-cli which I think would make it so we could have versions like 1.0.0 instead of 1.0.0-cli. Not really related to your issue but might be nice.