proposal: export `.tool-versions` finding and parsing logic
- Dominant language
- Go
- Stars
- 25.6k
- Forks
- 941
- Avg merge
- 9h 24m
- Merged PRs (30d)
- 3
Description
### Is your feature request related to a problem? Please describe
My particular use case is that I would like to write a plugin module for [powerline-go](https://github.com/justjanne/powerline-go) to give it support for asdf, but I think exporting that logic could be useful elsewhere, too.
If this idea is accepted, I can work on it and send a pull request.
### Describe the proposed solution
Move the `internal/toolversions` package to `toolversions` and update it to have a nice interface for public facing. Something like
```go
package toolversions
type Tool struct { ... }
// ForDir gets the versions of tools to use when in the given directory. It is an error for dir to point to a non-directory.
func ForDir(dir string) (iter.Seq[Tool], error)
// Version calculates the version of the tool that will be used.
func (t Tool) Version() (string, error)
```
The API isn't the main point, though. If changing it is too much trouble or has too far reaching consequences throughout the project, just exporting at least a subset of what's currently there, enough to find versions of tools, would be fine.
### Describe similar `asdf` features and why they are not sufficient
There are none.
### Describe other workarounds you've considered
Manually parsing the `.tool-versions` files. It's not exactly hard to parse them, but making sure that the logic for determining a specific version is exactly the same as asdf's and that it matches if that logic changes would be annoying, especially if that logic already exists in the same language that I'd be writing in anyways.
Contributor guide
Research direction
Start by inspecting the internal/toolversions package and its existing callers. Determine which finding and parsing behavior can be exposed without changing current consumers, then review the proposed ForDir and Tool.Version interface against the package's current behavior. Done means the logic is publicly usable for finding and resolving .tool-versions entries while existing project behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100