Support for detection of tool versions in .tool-versions file

[borjapazr]

Title: Support for detection of tool versions in .tool-versions file

Issue Description:
Currently, the project supports the automatic detection of Node.js versions through the .node-version file. However, it would be highly beneficial to extend this functionality to include detection of tool versions specified in the .tool-versions file.

Proposed Solution:
To achieve this, we can enhance the version detection mechanism to recognize and apply the specified tool versions from the .tool-versions file. This improvement will streamline the development process by ensuring that the correct tool versions are utilized consistently across different environments.

Expected Behavior:

• When a .tool-versions file is present in the project, the system should automatically identify and use the specified tool versions.
• In cases where a specific tool version is not available, the system should provide a clear error message or prompt the user to install the required version.

Additional Information:

• This enhancement will contribute to a more seamless and efficient development workflow, especially for projects that rely on specific versions of various tools.
• Compatibility with a broader range of tools will further empower developers and facilitate smoother collaboration within the project.

Steps to Reproduce:

1. Create a .tool-versions file in the project directory.
2. Specify the desired tool versions in the following format: tool_name version_number.
3. Run the project or relevant tooling that relies on version detection.

Acceptance Criteria:

• The system successfully detects and applies tool versions specified in the .tool-versions file.
• Clear error messages or prompts are provided in cases where a specified tool version is unavailable.

[jhheider]

I assume this is the spec for .tool-versions, based on a quick search?

[borjapazr]

I assume this is the spec for .tool-versions, based on a quick search?

Yes, sorry. I forgot to attach the source of that specification. Although it is something promoted by asdf, it is widely used to configure tool versions in development environments. Other tools like rtx also support this specification.

Thanks in advance 🙏

[yoroshikun]

This sounds good and would make it easier to migrate from rtx / asdf. (my previous go to)

[mxcl]

cool, can do and thanks for the copious detail! Probably if asdf or rtx are added to the env though we should delegate to them.

[sporkd]

My vote would be not to implement this. The .asdf file is specific to asdf, and right now I'm finding it very necessary to use asdf as a fallback if pkgx doesn't yet provide a package. So I am loading both the asdf shell integration as well pkgx shell integration. Some perfect examples where this is necessary is with Ruby versions lower than 3 and Node versions lower than 12.

So I only put packages in .tool-versions that I know pkgx does not yet provide, and I'd rather have pkgx.yaml and .tool-versions coexist independently and peacefully, rather than see a bunch of errors from pkgx when I cd into a directory with a .tool-versions file full of stuff I know isn't in the pantry. (And it's easy enough to migrate a .tool-versions file to a pkgx.yaml)

I guess the one caveat would be if pkgx could have this as a configurable option, much like asdf has legacy_version_file = no. Or even better if pkgx would continue processing and not just error out as soon as it hits a package it doesn't have.

[sporkd]

Okay, I just saw @mxcl comment about delegating to asdf if it's there. I guess that could work too🤔 . My concern is coming from difficulties I'm already having with pkgx trying to optimistically load anything it can find (package files, lock files, .ruby-version, .node-version, etc.). Often times I'm working in repos that other orgs own, with a bunch of legacy stuff that might not be easy to change. So I want to be able to just define a pkgx.yaml and not get a bunch of conflicting version errors when I try to cd into the dir. Delegating to asdf if in the path sounds like a good idea. But I also like a feature similar to asdf's legacy_version_file = no.