asdf-vm / asdf-vm/asdf

proposal: export `.tool-versions` finding and parsing logic

Open
#2,040 1 comment 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.