Asdf: .tool-plugins file

[nikolay]

I combine direnv with asdf for convenient self-contained project environments. I have a script that's executed typically once per project and it installs all missing asdf plugins and their versions stored in .tool-versions. This works, because I don't use legacy files such as .nvmrc. But even without using legacy version files, I still don't have a fully-automated process and a reusable script as the information within .tool-versions only has the plugin ID and not the source if it's not a standard plugin, let's say.

So, I propose the addition of .tools-plugins file. It would be a simple text file, having <plugin_name> [<plugin-source>] lines. What plugins would go in this file? First, custom plugins, which are not in the main plugin repository. Second, plugins, which versions are specified in legacy version files such as .nvmrc, not in .tools-versions. This way, by combining the data from .tool-versions and .tool-plugins, an automated script can install all missing plugins and the versions used by the project.

Then, you just have to clone an asdf-based project and run that shared script (which can and should be turned into a standard asdf command) and you'd have your new project's environment ready to use without having to dig into long and confusing documentation.

[vic]

I'd love something like this be implemented. I'm also interested in just sharing my project code base and with a single asdf command being able to install tool dependencies over a fresh asdf setup. Having that .tools-plugins file could help at least for non-standard plugins. I recon that installing plugins is still somewhat tedious for fresh asdf installs (ie it's still manual #210, or confusing #229).

Maybe we could search just like .tools-versions for that .tools-plugins and then fallback to an asdf-included .tools-plugins for defaults. (currently we do clone the asdf-plugins repo and check if a directory exists for an registered tool)

I'd pretty much be interested in hearing some feedback from both @asdf-vm/maintainers and users on using something like what you propose.

If you feel like it, please go on and help us with a PR, I'd love to help testing it.

[danhper]

I think this could be really helpful.

I have a Dockerfile which looks something like this

RUN asdf plugin-add nodejs
RUN asdf plugin-add python

RUN bash $ASDF_DIR/plugins/nodejs/bin/import-release-team-keyring

RUN asdf install

I would rather have something like asdf setup and have everything automated.

We do need to come up with something for plugins like nodejs which require to manually do something.
Maybe we could formalize this by having an optional PLUGIN/bin/init script and have a flag so that asdf setup (or whatever command name we decide to use) run all the init scripts automatically.

What do you think?

[nikolay]

I think asdf setup is a great choice, but then for consistency, maybe the plugin hook should also be called setup instead of init.

[danhper]

@nikolay I agree.

[nikolay]

@tuvistavie I will try to give it a shot if you don't mind.

[vraravam]

I have been explicitly browsing the issues in asdf for exactly this same reason! Could this be picked up on priority?

[stefansedich]

+1 as a recent asdf user this is also something I did not expect to run into, definately makes it a little more kludgy to use, I wonder if it could all be bundled into the .tool-versions file by providing a way to define the git url, for example:

tool-in-main-repo 1.0.0
tool-not-in-repo[https://giturl] 1.0.0

Perhaps even modity .tool-versions so that the URL is an optional column, could easily handle parsing it if it exists, something like:

tool-in-main-repo 1.0.0
tool-not-in-repo https://giturl 1.0.0

[aeons]

Is there any work going on for this?

It would solve several issues for our use case.

[jthegedus]

Anyone got the time to develop a solution to this?

[colinrymer]

While I'd love to have a built-in solution, the workaround I've been using is the following in my post-up hook for rcm:

   7   │ . /usr/local/opt/asdf/asdf.sh
   8   │
   9   │ for plugin in $(cat ../.asdf-plugins); do
  10   │     asdf plugin-list | grep $plugin > /dev/null 2>&1
  11   │     if [ $? -ne 0 ]; then
  12   │         asdf plugin-add $plugin
  13   │     fi
  14   │ done

where the .asdf-plugins file referenced is just a file with a plugin per line.

[Stratus3D]

Closing this as my general philosophy is that things that can be done outside asdf in a few lines of code should be kept outside of asdf core. I think we may eventually support installing plugins from .tool-versions files if the user wishes (#313, #276).

[jthegedus]

While thinking of solutions to #313 I don't think they can cover _what I believe_ the core of the request here, which is to ensure the same plugin source is used for a tool within a project.

With the current state of asdf-plugins only being a 1:1 relation we're currently the gatekeepers to plugins that could be installed in any automatic solution without also tracking the plugin used to install that plugin initially. The implications of using two different plugins on one system to install the same tool/shim is also uncertain (Eg: removing one of two plugins for a particular tool removes all installations of the tool even though there's still a managing plugin for one of the tools).

I'd also say that it's unclear if .tool-plugins is the right solution to these problems.

[Stratus3D]

@jthegedus I'm not sure if I am following you in regards to multiple plugins for the same tool, but I don't see that as something we should support. A plugin should be able to manage all versions of the tool available. It should be left up to the user which java or clojure plugin they choose to use, but they should be limited to one to keep things sane.

I'm not sure .tool-plugins is the right solution here either, but it might make it easier for the user to be more explicit about what plugins they want to use.

[jthegedus]

in regards to multiple plugins for the same tool, but I don't see that as something we should support.

I don't think we can support it either.

The scenario was: project A has a .tool-versions and .tool-plugins, project B has the same, but the plugin used for a shim differs between the two projects. How is a user to resolve this?

I agree that we shouldn't support this, but I also don't like any solution for automated plugin installation where we use asdf-plugins. I would like a solution where the user can define which plugin their asdf installation uses (not per project) via the plugin URL.

Another area I am unclear on is how a plugin is associated with a shim if the user can install the plugins with whatever name they want, but I digress.