-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.tool-plugins file #240
Comments
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 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. |
I think this could be really helpful. I have a
I would rather have something like We do need to come up with something for plugins like What do you think? |
I think |
@nikolay I agree. |
@tuvistavie I will try to give it a shot if you don't mind. |
I have been explicitly browsing the issues in |
+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:
Perhaps even modity .tool-versions so that the URL is an optional column, could easily handle parsing it if it exists, something like:
|
Is there any work going on for this? It would solve several issues for our use case. |
Anyone got the time to develop a solution to this? |
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:
where the |
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 I'd also say that it's unclear if |
@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 |
I don't think we can support it either. The scenario was: project A has a I agree that we shouldn't support this, but I also don't like any solution for automated plugin installation where we use 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. |
You don't need a new file. |
In case it is helpful for anyone else who lands here, here's what I came up with: cut -d' ' -f1 .tool-versions | sort \
| comm -23 - <(asdf plugin-list | sort) \
| join -a1 - <(asdf plugin list all) \
| xargs -t -L1 asdf plugin add |
I kinda took this whole idea to the extreme haha Anyway feel free to check out https://github.com/brad-jones/asdf-bootstrap |
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Since it looks like there is no solution provided so far in asdf itself, I've created a plugin called asdf-plugin-manager to fix that issue and to manage asdf plugins securely and declaratively.
Or
|
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.
The text was updated successfully, but these errors were encountered: