Multiple Tooling Profiles per Project

[diraneyya]

Is your feature request related to a problem? Please describe

rustdesk/rustdesk#9412

This idea might sound complex but if tackled carefully, it could make up for a nice addition to asdf (hopefully without overcomplicating this, otherwise, delightful utility). The suggestion is to support multiple .tool-versions files, or multiple mutually-exclusive tools versions per project, allowing one of them to be activated at any given time.

USE CASE: A major barrier to contributing to the RustDesk project has been the complexity of the build process. This discourages community contributions to an otherwise fantastic project while maintainers remain overburdened and unable to offer support.

Currently, the project requires managing version control for:

• flutter
• rust
• vcpkg
• cmake
• nasm
• (maybe) ruby

The challenge lies in determining the correct combination of versions to build the app. At the moment, the GitHub Action workflow files in the repository serve as the single source of truth.

Although the build documentation for RustDesk does not currently mention asdf, I identified it as a clean solution for managing tool versions. However, RustDesk might require different versions of tools depending on tasks—for example, generating Dart code from Rust versus performing the final build.

Currently, the developers are encouraged to run the GitHub actions or use Docker for the build, which I have not tried to be completely frank (I am building the MacOS X app on an Apple Silicone MacBook pro with Xcode and all).

This complexity led me to consider the possibility of extending asdf to support this workflow natively.

Thank you for your time and any constructive feedback you can provide!

Describe the proposed solution

Extend the .tool-versions syntax to support the following capabilities:

1. Allow specifying alternative versions for a single plugin. (not consumed by the plugin but by asdf)
2. Enable switching between pre-defined sets of plugin versions for specific workflows.

The challenge would be to preserve compatibility and maintain the tool's simplicity. As an alternative, symbolic links could achieve similar functionality but are less elegant.

Describe similar asdf features and why they are not sufficient

Currently, multiple local versions are handled by some plugins (e.g. Python) rather than being managed by the tool itself.

Describe other workarounds you've considered

Create symbolic links:

.tool-versions links to .tool-versions-build1 or .tool-versions-build2 based on workflow.

script activate_tooling.sh:

ln -sF ".tool-versions-build$1" .tool-versions

Usage

Switch to build1

Use:

./activate_tooling.sh 1

After than executing ls -la .tool* gives:

lrwxr-xr-x@ 1 orwa  staff  21 Jan 17 16:44 .tool-versions -> .tool-versions-build1
-rw-r--r--@ 1 orwa  staff  59 Jan 17 16:42 .tool-versions-build1
-rw-r--r--@ 1 orwa  staff  57 Jan 17 16:39 .tool-versions-build2

And typing rusc --version gives 1.75.0

Switch to build2

Use:

./activate_tooling.sh 2

After than executing ls -la .tool* gives:

lrwxr-xr-x@ 1 orwa  staff  21 Jan 17 16:44 .tool-versions -> .tool-versions-build2
-rw-r--r--@ 1 orwa  staff  59 Jan 17 16:42 .tool-versions-build1
-rw-r--r--@ 1 orwa  staff  57 Jan 17 16:39 .tool-versions-build2

And typing rusc --version gives 1.81.0

[diraneyya]

I would like to add a usability aspect of this proposed feature when using a fancy shell such as Starship:

[diraneyya]

BTW I would be happy to work on this once we figure out if it is something that interests the community and agree on the right way to do it