proto install for github tool tagged not using semantic version (toml plugin)

[shanipribadi]

What version?

0.41.3

Which command?

proto install kondo

What happened?

I'm using the following toml plugin definition (explicit versions instead of resolve.git-url due to the project not creating a tag for releases)

name = "kondo"
type = "cli"

[resolve]
versions = ["0.8"]

[platform.linux]
archive-prefix = "kondo-{arch}-unknown-linux-{libc}"
download-file = "kondo-{arch}-unknown-linux-{libc}.tar.gz"
checksum-file = "kondo-{arch}-unknown-linux-{libc}.tar.gz.sha256"

[platform.macos]
archive-prefix = "kondo-{arch}-apple-darwin"
download-file = "kondo-{arch}-apple-darwin.tar.gz"
checksum-file = "kondo-{arch}-apple-darwin.tar.gz.sha256"

[platform.windows]
archive-prefix = "kondo-{arch}-pc-windows-msvc"
download-file = "kondo-{arch}-pc-windows-msvc.zip"
checksum-file = "kondo-{arch}-pc-windows-msvc.zip.sha256"

[install]
download-url = "https://github.com/tbillington/kondo/releases/download/v{version}/{download_file}"

[install.arch]
x86 = "i686

Getting

❯ proto install kondo
Error: plugin::call_func::failed

  × Unknown version format `0.8`. Must be a semantic or calendar based format. at line 1 column 107

Although the crate in https://github.com/tbillington/kondo actually follows semantic version (they tagged the crate as 0.8.0), but the github releases are not tagged as such.

Would this be a scenario that proto toml plugin should be able to handle,
or should we actually ask upstream to tag their releases with semantic version instead?

Trace logs?

No response

Operating system?

Linux

Architecture?

x64

[milesj]

I unfortunately think this is one of those situations where a WASM plugin is required, since you would need to format/parse versions yourself. For example, go requires this: https://github.com/moonrepo/tools/blob/master/tools/go/src/version.rs

proto requires a fully-qualified version (needs the patch), but if we fill it for you and turn 0.8 into 0.8.0 or something, this version will no longer work for the {version} token.

I'll see if there's something I could do on my end.

[shanipribadi]

Thank you,
actually for the kondo repo, I've managed to make proto install it by running proto install kondo 0.8.0 and hardcoding the version in the download-url to 0.8 (and setting up version-pattern so it parses the git-tag properly).
Also, it's a global tool that doesn't really need to have per-project versioning.

[resolve]
git-url = "https://github.com/tbillington/kondo"
# versions = ["0.8.0"]
version-pattern = "^v?((?<major>\\d+)\\.(?<minor>\\d+)(\\.(?<patch>\\d+))?)"
...
[install]
download-url = "https://github.com/tbillington/kondo/releases/download/v0.8/{download_file}"

Looking at the proto-tool code,
I noticed that it parses VersionSpec from either git-tag, strings from a manifest file, or resolve.versions.

For this repo itself, the git-tag matches the actual part of the github download url,
so if we have that as another template variable it can be used.

or alternatively,

have [install.version] to allow overriding the {version} template variable just like [install.arch] and [install.platform].
so we could just have

[resolve]
versions = [0.7, 0.8]

[install.version]
"0.7.0" = "0.7"
"0.8.0" = "0.8"

[install]
download-url = "https://github.com/tbillington/kondo/releases/download/v{version}/{download_file}"

Let me know if you're open for PR on the above in the moonrepo/tools repo.

[milesj]

I think maybe supporting tokens like {versionMajor} and {versionMajorMinor} or something may also work?

[shanipribadi]

the only issue with {versionMajor} {versionMinor} {versionPatch} would be if upstream for some reason have this weird convention of

0.8.0 => 0.8
0.8.1 => 0.8.1
e.g. golang (hence you have that conditional on the go wasm plugin for when minor is 0).

although for this particular upstream, they had never tag a non-zero patch version so far (except the very first one),
so it would work for this particular case.