So, ubi is deprecated now, why tho and in what way?

[jinnatar]

I'm not finding any "why" or reasoning on why ubi is now deprecated and if it's the kind where it's "will no longer receive updates" or "will be gone in the release"? The docs push to use the github backend instead, but that's just a subset of what ubi is capable of and the syntax for working with difficult release artifacts is completely different and much less a "just use github" and more of a "completely figure out all over again how to match the correct thing"¹.

Is there a way to run the github backend in interactive debug mode somehow? It's getting a bit tedious to modify mise.toml fiddling with asset_pattern & friends, uninstall the package, mise install again and hope it works this time. Also asset_pattern isn't exactly documented, but it seems to be a basic glob and not regex, which isn't really good enough sometimes. Also the errors it emits are a bit useless, what I think it's saying is that it needs to match one and only one asset, but what it's saying is that it "doesn't match" which just isn't true. I'd report all of these as bugs, but as this project doesn't want bugs reported, not much I can do. 🤷‍♀️

Footnotes

1. The hardest one I've been trying to port is getting vlogscli installed from https://github.com/VictoriaMetrics/VictoriaLogs/releases/tag/v1.42.0. It's hiding in vlutils-linux-amd64-v1.42.0.tar.gz but good luck matching that instead of vlutils-linux-arm64-v1.42.0-enterprise.tar.gz. ↩

[jdx]

it doesn't make sense to maintain 2 backends that do the same thing. I was able to get github to replace all of the tools in the registry with ubi so it seemed like a good time to label it deprecated. It will probably receive patch updates but it will probably get removed in a few months or a year.

[jinnatar]

Does this then imply that we should implement for example forgejo/codeberg as a new backend instead of amending the ubi one?

[jdx]

yeah, we have the gitlab one so I don't think this would be that hard

[jinnatar]

The core question has been answered (Thanks!), I'll split out some of the sharp corners into new ones if I can't figure them out with more digging.

[jdx]

would this long-form syntax work for victoriametrics? should we just add it to the registry?

mise/registry.toml

Lines 1323 to 1340 in bad6c26

	[[tools.dome.backends]]
	full = "github:domeengine/dome"
	[tools.dome.backends.options.platforms.macos-x64]
	asset_pattern = "dome-v{version}-macosx-all.zip"
	bin_path = "dome-macosx-all"
	[tools.dome.backends.options.platforms.macos-arm64]
	asset_pattern = "dome-v{version}-macosx-all.zip"
	bin_path = "dome-macosx-all"
	[tools.dome.backends.options.platforms.linux-x64]
	asset_pattern = "dome-v{version}-linux-x64.zip"
	bin_path = "dome-linux-x64"
	[tools.dome.backends.options.platforms.windows-x64]
	asset_pattern = "dome-v{version}-windows-x64.zip"
	bin_path = "dome-windows-x64"

[jinnatar]

It might, just a whole bunch of platforms to include. Honestly I'm wishing for a negative matcher, something like asset_anti_pattern. If I could filter out the ones that for sure are wrong, then the platform autodetect could probably handle the rest.

[jinnatar]

Are the asset_pattern matchers documented anywhere? Definitely not in the github backend docs. I see now that with something like vlutils-{os}-{arch}-v{version}.tar.gz I'm very close (x64 vs amd64 being the last failure)

[jdx]

it isn't, I probably should make it use tera templates so that you could have a conditional. The probably easier alternative though would be to get it into aqua

[jinnatar]

Reading what little I understand of asset_matchers.rs it seems like it should already match both amd64 and x86 .. but perhaps that's not the right code to be looking at.

I'll see about aqua, but honestly the victoriametrics & victorialogs release strategy is so thoroughly insane I'm not sure if anyone would sign off on the dirty tricks to match it.

[jdx]

at this point I don't think I've seen a format that aqua couldn't handle on github