mise icon indicating copy to clipboard operation
mise copied to clipboard

refactor: provide ToolRequest for some backend operations

Open roele opened this issue 8 months ago • 2 comments

This is ~draft for~ a slight refactor to address issues with tool options for operations such as ls-remote, outdated or upgrade (see #4020)

This alters some Backend trait methods to take a Option<ToolRequest> argument which can be used for example in list_remote_versions to get the ToolOptions. Currently this happens via BackendArg (self.ba().opts()) which is not the correct approach since the backend might not have any tool options for a certain version. This also led to code in mise_toml.rs which copies the tool options to the BackendArg which now could be removed.

Additionally this partially solves another issues with tool options recently reported. Java EA releases cannot be discovered via ls-remote. With this fix this would be possible via mise ls-remote java[release_type=ea]@openjdk-25 (versions host interferes here so an additional method allows to disable the usage)

roele avatar Apr 20 '25 13:04 roele

so I need some more time to think about this. This doesn't fit my mental model of how things like list_remote_versions should work. I'm particularly concerned about how this may impact things like ls-remote and caching.

I'll get back to you this week with what I think we should do.

jdx avatar Apr 22 '25 17:04 jdx

I also tried to make sense for the reason why BackendArg is having ToolVersionOptions. Most of the time these are not populated (empty) because the backend is built when this information is not available or via a mise.toml which would have it but requires us to copy this information over. In the end there seems to be no reliable way to get these and we have to check both ToolRequest and BackendArg.

Listing remote versions and remote version cache are certainly an issue.

How can we list versions hosted on GitLab unless we use mise ls-remote ubi:gitlab-org/cli[provider=gitlab]? Or discover Java EA versions via mise ls-remote java[release_type=ea]@openjdk-25. This also affects other commands such as outdated and upgrade both using latest versions.

Since the remote version cache key (BackendArg.full()) and file name do not contain endpoint information the GitLab versions will be cached and mise ls-remote ubi:gitlab-org/cli (which should reach out to GitHub) would return GitLab versions. But i guess thats an edge-case since you usually don't fetch the same tool from different URLs.

🤔 ~Maybe there should be a method (e.g. get_remote_version_cache_key) to overwrite the remote cache key for a backend so we can provide different caches for different endpoints (would also work for the Java use-case). But this method would also require access to the ToolVersionOptions though.~ Instead of adding a method to disable support we could just provide our own remote cache implementation for Java but the method will also need the ToolRequest.

roele avatar Apr 22 '25 18:04 roele

Closing this as discussed and raising a new one with a less intrusive solution.

roele avatar Apr 28 '25 15:04 roele