-
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
Ability to specify plugins in a file #829
Comments
Just wanting to add, that a plug-in that is referenced in the |
@T4cC0re yeah that might be a good catch for 90% of use cases... defaulting to a plugin that's in the registry, if it exists, is less intrusive than what I'm proposing. Let's see what the maintainers say, and I'm happy to send a PR for either approach. |
Related - #240 |
@Stratus3D thanks, I obviously didn't search hard enough for pre-existing issues! Which of #240, #276, or #313 best represents your current thoughts on the matter? #240 was closed without implementation. I think specifying plugins in one global place, e.g. There are lots of good points raised in those issues around rough edges with some of the proposed implementations (e.g. #313 (comment)), but a single global plugin location is an iterative improvement on today, where plugins must be installed out-of-band. |
I think it is safe to say specifying in the
See my most recent comment on #313 (comment)
Wherever we define the list of plugins, we will effectively be defining a new API in the form of an extremely simple DSL. This is better than a complex DSL, but it is still yet another API that we have to maintain. Quoting what I said on #313 (comment),
I personally don't see any problem with putting this in a script like below (which works today): #!/bin/bash
# Script to setup my plugins
asdf plugin-add ruby
asdf plugin-add nodesjs https://some.custom/nodejs/repo.git Or using @colinrymer's approach - #240 (comment) Both of these have the benefit of reusing asdf's existing API. |
Yeah definitely - I say this in the issue description, but in hindsight I should have just removed that part altogether. The linked approaches are fine, and as you say are not a lot of work to implement. The problem with them, and I admit it's a minor problem, is that every asdf user must implement pretty much exactly the same orchestration over asdf's API to version control their plugins. That leaves opportunity to centralize that admittedly simple code in the tool itself, to add value for users. From #313 (comment):
This is fair, and I understand that it's out of scope for asdf to resolve dependencies of plugins. What I'm still not understanding is what that fact has to do with the various proposals for version-controlled, global, plugin lists. Users already have to consider dependencies of plugins, if that plugin has any, before installing them - whether another asdf plugin can provide that dependency or not. I'm not proposing to change that. |
@craigfurman In the scenario you outline where a new user sees your Discoverabiltiy here is an interesting problem, especially if the plugin source is a company internal mirror/fork of an open-source plugin. As suggested, proposed solutions fail to identify that plugins are global to the machine, not specific to a project. Two different users with different plugins for the same tool should not particularly matter at the IMO we're left with this:
Communicating device to device configuration is not best done on a project level, so I think the best solution thus far to this problem is to:
I don't think we document you can have comments in this file, so perhaps that's our bad there. Perhaps there's room for us to automatically comment above each I think people are giving too much weight to plugins as they're merely a wrapper around downloading, installing and identifying executables to shim. Ideally they should all be doing the same thing (I understand some vary with support of installing various runtimes eg: python and anaconda with the python plugin). |
@jthegedus you're right that any system-global solution doesn't really address discoverability at the project level. I see now that I re-read my own issue description that the solution I propose doesn't address the stated problem! On the one hand, any assumptions that an individual Even though it has swung the conversation back to project-based solutions, I do like your idea about automatically installing standard plugins, and falling back on a configured non-standard plugin. |
So to resolve this issue I think we have two steps to take:
Thoughts on 2. @asdf-vm/core ? |
Can be as simple as #240 (comment) |
@jlurena yep, I currently use an almost-identical script. I would still advocate for adsf doing something to automate plugin installation, despite the friction between local ( |
I was unable to find a suggestion for this solution, but I was looking at this problem from this perspective: If I specify in The answer of course is no and I think that is good. What I did expect however, which might be able to thread between the lines, is just to output a warning message like:
Thoughts? Feels like a way to highlight the potential dependencies without making choices for the user. |
Yes, this is one thing that I stumbled over when I first used asdf as a consumer. Displaying there are missing plugins and what they are leaves the user with clues on how to proceed. I would welcome something like this. |
Identifying a missing plugin on the local system from the items in |
This issue is a dupe of #240. |
I don't know if it's worth opening an entire separate feature request for my idea, but it would be nice to be able to specify the fully qualified plugin path in For example:
I know people keep going on about how plugins are system global, but this is unambiguous as to exactly what you're asking asdf to install, and removes the "how do we map plugin shortnames to URLs" problem in a very clean and obvious way. Alternatively, if a plugin shortname is required, then maybe a syntax like this would suffice:
|
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
|
Manage asdf plugins securely and declaratively. Fixes: - asdf-vm/asdf#166 - asdf-vm/asdf#240 - asdf-vm/asdf#829 - asdf-vm/asdf#1577
Is your feature request related to a problem? Please describe.
I work with a lot of projects that check in
.tool-versions
, because I like using asdf 👍. However, it's not always obvious to new users which plugins they need to install. This is a particular problem for plugins that are not in the official plugin list.Describe the solution you'd like
We could specify plugins in
.asdfrc
. I've not looked deeply into parsing asdfrc, or its format, so I'm not sure what form the syntax should take yet.I had previously thought about specifing plugins in
.tool-versions
, e.g.But, plugins are global to asdf, so perhaps this isn't a good idea in case different
.tool-versions
files conflict.Update: I've edited this section to make it clear that a
.tool-versions
, project-specific solution is not what I proposed, but was something I thought about then discarded.Describe similar asdf features and why they are not sufficient
Describe workarounds you've considered
Additional context
The text was updated successfully, but these errors were encountered: