Skip to content
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

feat: pass --add to asdf install to add plugins in .tool-versions #313

Closed
wants to merge 2 commits into from
Closed

feat: pass --add to asdf install to add plugins in .tool-versions #313

wants to merge 2 commits into from

Conversation

trs
Copy link

@trs trs commented Apr 24, 2018

Summary

asdf install --add will add any plugins from .tool-versions before installing them (if they are in the repo), saving time and effort when adding plugins listed there.

Fixes: #276

Let me know if more needs to be done to satisfies security concerns or anything.

@danhper
Copy link
Member

danhper commented Mar 24, 2019

Thanks for the PR and very sorry for the huge delay.
This feature has been asked for a couple of times and I think this could be helpful.
@asdf-vm/core Any opinion on this?

@trs
Copy link
Author

trs commented Mar 25, 2019

No worries! I've rebased this against master.
Let me know if there's anything else I can help with.

@jthegedus
Copy link
Contributor

@danhper I believe the main reasons for not adding this so far was because there may be multiple plugins used for the same lang/framework/tool. For instance https://github.com/Banno/asdf-hashicorp

@danhper
Copy link
Member

danhper commented Mar 26, 2019

@trs Thanks a lot!

@jthegedus I am not entirely sure I get it. If the plugin does not exist, this would just be equivalent to running

asdf plugin-add PLUGIN_NAME

which will use the plugin registered in our asdf-plugins repo with this name.
If somebody wants a different plugin with the same name, he can always run asdf plugin-add PLUGIN_NAME URL and then even if the --add flag is passed, the plugin will not be updated or anything.
Am I missing something here?

@kvokka
Copy link

kvokka commented Jul 5, 2019

I like the idea of this feature.

If the user want to check the the repos for security, he should do it anyway.

With out this feature all earlier mentioned security problems are at the same place- it just help to reduce the annoying installation process.

Asdf tool does not contain any tool, which have 2 official repo, so it does not looks like a problem.

This branch is outdated, if you want, I can rebase it and add missing docs.

trs added 2 commits July 5, 2019 13:34
`asdf install --add` will also add any plugins from `.tool-versions` before installing
@danhper
Copy link
Member

danhper commented Jul 22, 2019

@trs Thanks for rebasing!
@Stratus3D @jthegedus I think this is a good addition, any opinion?

@jthegedus
Copy link
Contributor

My only opinion is that I am keen to see this land! Will certainly help me onboard new users at work.

@danhper
Copy link
Member

danhper commented Jul 23, 2019

Ok, great! Feature-wise I think it's good but we do need some tests.
@trs Do you think you would have time to add tests for this feature, please?

@aliuk2012
Copy link

It's been over a year now, is there any progress on this feature. It would make a huge difference to be able to confidently know that when joining an existing project that uses asdf that you could install all its tools with two or less commands instead of manually running asdf plugin add ... a number of times.

@jthegedus jthegedus self-assigned this Sep 2, 2020
@jthegedus
Copy link
Contributor

jthegedus commented Sep 2, 2020

@aliuk2012 Sorry this has lagged, we've been making our way through some of the open PRs and trying to finish off our 0.8.0 release. I will commit myself to addressing this soon (likely after 0.8.0 release).

I think the only remaining questions around this are:

  • test cases to track the effect of the flag on this command and identify future regressions. If someone has the time over the next week to add those that would be appreciated, else I will get to it soon.
  • list URLs of plugins to be installed and let user confirm they agree to install said plugins addressing security concerns mentioned in original Issue Feature Idea: asdf install to also install plugins #276
  • configuration option to control automatic confirmation of plugin installation
  • rename the flag to --with-plugins or --plugins-and-versions (IMO more clearly communicates with the users the intent of the flag)

I think the biggest concern I have with this solution is the dependency on the asdf-plugin repo and the fact that the plugin repo only has one repo per plugin name. I have been toying with asdf-plugin repo ideas that would break this 1:1 model and subsequently break these types of features.


As another thought, implementing a solution to #240 would enable a simpler solve to all the issues here and in #210 / #651 potentially without adding more flags or adding security warnings because the users have already opted-in to each particular plugin URL 🤔

@jthegedus jthegedus added this to the v0.9.0 milestone Sep 3, 2020
@Stratus3D Stratus3D mentioned this pull request Sep 17, 2020
@jthegedus
Copy link
Contributor

jthegedus commented Sep 18, 2020

Further thoughts on this feature request

  • How would missing system dependencies be handled for plugins? The python plugin for instance requires both pyenv deps and python build deps
  • How are plugins installed that are not in asdf-plugins? perhaps your company have their own internal plugins or forks of public plugins vetted by security which download from internal mirrors of public repos?

I was too hasty in my previous comment to commit this to the next major release as there's increasingly more scenarios where this feature introduces more problems for the user than solves.

The issues it solves are actually required setup of the tool. There's certainly room to move and improve, but I don't think this is necessarily the right solution (happy to be convinced otherwise).

So in a complete 180 I'm going to remove the milestone tag until this becomes more clear.

@jthegedus jthegedus removed this from the v0.9.0 milestone Sep 18, 2020
@Stratus3D
Copy link
Member

I was too hasty in my previous comment to commit this to the next major release as there's increasingly more scenarios where this feature introduces more problems for the user than solves.

The issues it solves are actually required setup of the tool. There's certainly room to move and improve, but I don't think this is necessarily the right solution (happy to be convinced otherwise).

I agree with @jthegedus on this. This pull request solves the easy part of the problem - running asdf plugin-add <plugin> - and doesn't address the hard part that users will have to perform manually - installing dependencies and setting up the environment for the tool. asdf is just a version manager it, doesn't setup the environment.

I suggest we close this PR. I understand things like this would make developer easier for many folks, but I don't think this is the right approach. I think asdf should provide small, focused, stable API so that other developers can build their own tooling around asdf for things such as environment setup. I'm happy to provide input if @trs or other developers want to build additional tooling around asdf's current API.

@jthegedus
Copy link
Contributor

jthegedus commented Dec 6, 2020

I concur with @Stratus3D summary. I think our effort would be better spent improving our API and documenting reciepes to perform these extra little tasks, as they aren't core and solve auxilliary problems not covered by the asdf tools design.

@codyrobbins
Copy link

I wish this could be revisited. I feel like the step of adding plugins is entirely superfluous: asdf knows exactly what plugins are installed and from .tool-versions it knows which ones need to be installed—why do I have to manually go through the motions of running an incantation myself for no reason? For context, I’m primarily looking at this from the viewpoint of onboarding new developers to a project and it looks like a number of people above are too. Sure, instructions for this can go in a readme or a bootstrapping script, but… why? It can just happen automatically.

I understand the security implications of automatically running code, but I think strategies for dealing with this were properly addressed in #276 in terms of making this behavior opt-out via .awsrc or opt-in via an --add flag. And I think closing this because it doesn’t solve all possible problems is kind of silly. This change would be an improvement—even if there are all sorts of various edge cases like plugin dependencies and environment configuration that it doesn’t address. But why does it need to?

I really love asdf but the conscious choice not to merge this seems like making perfect the enemy of the good.

@ngyewch
Copy link

ngyewch commented Dec 21, 2022

@codyrobbins I've got a simple tool for this. I ran into the same problem myself. https://github.com/ngyewch/asdf-helper

@sheldonhull
Copy link

I ended up switching everything to aqua which fit the bill, and has some additional steps to harden security. Binary installs, pinning versions, very easy to contribute new tools, checksum verification, cross-platform, global vs project installs.

It doesn't handle runtimes, like Python, so asdf is better for that, but since I work with Go, it ended up taking care of every tool I need. If you are in a different ecosystem with runtime tooling dependencies for specific versions of python, ruby, etc, then asdf is probably a better fit for those. For all other binary based tools, highly recommend checking out aqua.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Idea: asdf install to also install plugins
9 participants