Allow environment variables to be specified in tool-versions

[iloveitaly]

Some projects require additional configuration options for packages to be specified. It would be great if these could be specified in the tool-versions file, allowing a simple asdf install, which would avoid additional installation instructions in a readme.

Describe the solution you'd like

Ability to specify environment variables for specific installations within tool-versions. Something along the lines of:

export PYTHON_CONFIGURE_OPTS="--enable-framework"
python 3.7.10

[jthegedus]

After thinking about this for a few days, my thoughts are:

I don't like the proposal because it only applies to one use case of the asdf install command (that which reads the .tool-versions file and attempts to install each tool:version pair within). That specific use case of asdf install was added as a utility function to ease the singular specific case of bumping all tools at once in a single project.

This further clouds the usage of asdf install which is most commonly used without a .tool-versions file.

Will leave this open for further discussion.

[themartorana]

Ran into a need for this today. Flutter has a FLUTTER_ROOT env variable that specifies where Flutter is installed. Although I can do something like export FLUTTER_ROOT="$(asdf where flutter)" this executes when my shell session begins, and is always the global install root. When I enter a directory where I am running an asdf local setting, I need to be able to update the FLUTTER_ROOT env variable.

[RobLoach]

You could possibly use something like this: https://github.com/excid3/asdf-vars

[iloveitaly]

Bummer that asdf-vars uses a separate file. https://direnv.net seems like a more mature approach and uses a separate file as well.

[jthegedus]

Bummer that asdf-vars uses a separate file. direnv.net seems like a more mature approach and uses a separate file as well.

There is an integration for direnv - https://github.com/asdf-community/asdf-direnv

[RobLoach]

Didn't know of direnv! This is great, thanks.

[hyperupcall]

Would like to add my input and say that I'm not for this proposal either. Currently, .tool-versions is strictly declarative and this would make it much more imperative. Not to mention that there will be side effects that will need to be dealt with. I might be a bit biased though, because I'm building a tool that aims to have 100% compatibility with the existing .tool-versions file, so this would make it more difficult.

Also direnv was mentioned, which already solves this perfectly - I myself maintain the popular autoenv, and there are still some unanswered questions related to how and when to "unload" [environment ]variables (and deal with side-effects). So all in all I think its better to delegate this responsibility to a different tool and not implement it yet again in another tool

[iloveitaly]

I'd agree here—I think direnv/asdf-vars approach makes more sense given the small scope of the responsibility the .tool-versions has.