Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: export .tool-versions finding and parsing logic #2040

Open
DeedleFake opened this issue Mar 25, 2025 · 1 comment
Open

proposal: export .tool-versions finding and parsing logic #2040

DeedleFake opened this issue Mar 25, 2025 · 1 comment

Comments

@DeedleFake
Copy link
Contributor

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 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

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.

@DeedleFake
Copy link
Contributor Author

Upon further inspection, it appears that the internal/resolve package is actually the one that handles the higher-level logic of both finding and parsing the .tool-versions files. Either way, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant