Closed sgtsquiggs closed 6 months ago
The issue is that https://github.com/digitalocean/gta has no tagged versions. The failure however is a little confusing since you can install from SHA, which is not a true version, as long as there is at least one tagged version of the module.
@endigma I can make this work by returning empty vec
s on errors, but not really sure if that would just create silent failures for other scenarios.
fn list_remote_versions(&self) -> eyre::Result<Vec<String>> {
self.remote_version_cache
.get_or_try_init(|| {
let mut mod_path = Some(self.name());
while let Some(cur_mod_path) = mod_path {
match cmd!("go", "list", "-m", "-versions", "-json", cur_mod_path).read() {
Ok(raw) => {
let result = serde_json::from_str::<GoModInfo>(&raw);
if let Ok(mod_info) = result {
return Ok(mod_info.versions);
}
mod_path = trim_after_last_slash(cur_mod_path);
},
Err(_) => return Ok(vec![]),
}
}
Ok(vec![])
// Err(eyre!("couldn't find module versions"))
})
.cloned()
}
It would be best if we could somehow get a fuller list of valid versions, including git shas, or maybe just regex for a git sha and accept that fast? idk how that would work with updater code though, haven't looked at it.
@jdx does update code just pick the first version in the vec or could it potentially be split into some sort of channels thing? ("git" vs "release" ? this could affect npm as well)
Perhaps just need to support the ref:sha
syntax? Or is it supported if there is at least one version available?
Perhaps just need to support the
ref:sha
syntax? Or is it supported if there is at least one version available?
@SHA
worked when I tested it on a module with at least one tagged version.
The trick with supporting SHAs as part of building upgrade paths IMO is that commit logs are not linear in the sense that they branch and form ancestry trees rather than an ordered sequence. From a modeling standpoint I think refs would just have to be treated as terminal versions and upgrading would force you back on the properly versioned edge.
That's true in some sense, but "git" as a version pretty commonly means HEAD of the main branch, and that series of shas can be interpreted as a version list in some sense. Although force pushes could be evil here. (unless this just works by "upgrading" to the latest HEAD no matter where it is in relation to the previous HEAD? Is this how aur -git
packages work? Those seem to be fine)
A short-term solution here short of different "channels" of versions for any given package in the forge impl would be to add some sort of regex to shortcut the go "valid version checker" with a regex for a git sha. The only actual usability issue here at the moment is that mise expects a valid version list from every installable thing, not just go packages. We could just do what @Ajpantuso wrote above and return an empty vec instead of Err, as a patch. go install
will fail for any invalid version using its own internal checking code anyway.
My expectations were that using a sha completely bypasses any versioning. This is really an edge case - most go tools would have a version. I forked this repo and versioned it to make it work with mise 🤷♂️
This isn’t a strong ask, just bad assumption (on my part)
Yeah, my intuition is that a SHA version should be treated as if it was outside the versioned upgrade path and upgrade logic would only "upgrade" by bringing the version back to the latest available which could very well be an ancestor from a commit log point of view.
You can probably PR the empty vec solution, at least as a bandaid. Usable > perfect for now
Describe the bug
mise use go:github.com/digitalocean/gta/cmd/gta@a677131
fails yetgo install go:github.com/digitalocean/gta/cmd/gta@a677131
does not.To Reproduce
Expected behavior It should install. I can install it via
go install
:mise doctor
outputAdditional context Add any other context about the problem here.