Allow configuring asdf to use a custom plugin repository

[shakefu]

Is your feature request related to a problem? Please describe

Yes, right now asdf has hard coded the plugin repository which maps names to repository URLs.

https://github.com/asdf-vm/asdf/blob/master/lib/utils.bash#L36

This means it cannot be used in high-security or airgapped environments.

Describe the proposed solution

Allowing the plugin repository to be configured through environment variable would be trivial, or perhaps through a new setting in ~/.asdfrc.

Describe similar asdf features and why they are not sufficient

N/A

Describe other workarounds you've considered

Create a fork of asdf-vm/asdf and edit it directly.

[hmnd]

Though I know this doesn't entirely solve the issue, you can already provide your own Git URL to a plugin without having to go through the centralized repo. See here. The docs even suggest always using the long method to avoid reliance on the central repo.

[shakefu]

here

This is true, but my specific use case includes being able to specify .tool-versions, without knowing ahead of time which tools are going to be installed, and which repository URIs should be added for the plugins. This means it will use the default plugin name mapping instead, which is what I'd like to override.

Of course, it would be fairly trivial to cat .tool-versions | awk '{print $1}' | xargs -I{} asdf plugin add {} github.com/myorg/asdf-{} but ... that's exactly what the default plugin repository is doing...

[hmnd]

This might interest you too :) #240 (comment)

[jthegedus]

Please read #952 (comment)

We don't particularly like the plugin repo solution and want to move away from it. Making it configurable turns it into a public API which it wasn't designed for and we don't want to do.

asdf plugin <name> <url> is a repository agnostic solution, please prefer it.

I am inclined to close this as it has been discussed and closed before and our position has not changed.

[shakefu]

TBH my biggest problem with asdf as a user (use cases above not withstanding) is actually finding plugins for various tools that aren't in the short-name "plugin repo". Regular search engines and

I still think there's a strong use case in high security/air-gapped environments to only allow short-name plugins from a pre-approved/security vetted "plugin repo" list, but if it's not part of the intended long term road map, obviously you can close this.

Thanks for the replies. 👍

[jthegedus]

I still think there's a strong use case in high security/air-gapped environments to only allow short-name plugins from a pre-approved/security vetted "plugin repo" list, but if it's not part of the intended long term road map, obviously you can close this.

You could have a single internal repo at an org that is used as the approved, high-security plugin repo, you would just need to use asdf plugin add <name> <url> pattern to install. The shortname saves you typing the URL. The only benefit to the shortname repo is discoverability and to save on typing. Neither of which should impact an approved, high-security plugin repo.

[jthegedus]

Discoverability is an area of improvement without the plugin repo, but I assure you this will be a primary concern with any alternative solutions. However, we do not intend to make the plugin repo an public API. I will close as with #952

[jthegedus]

#1227 added support to disable the plugin repo for those who wish to force explicit use of asdf plugin add <name> <url> workflows.