You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
typeToolstruct { ... }
// 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.funcForDir(dirstring) (iter.Seq[Tool], error)
// Version calculates the version of the tool that will be used.func (tTool) 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.
The text was updated successfully, but these errors were encountered:
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.
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 totoolversions
and update it to have a nice interface for public facing. Something likeThe 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 sufficientThere 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.The text was updated successfully, but these errors were encountered: