Make add-on loading configurable

[rolandcrosby-columntax]

I have checked that this feature is not already implemented

• This feature does not exist

Use case

The Ruby LSP currently unconditionally tries to load add-ons from any ruby_lsp/**/addon.rb file in any installed gem. If you have a gem installed that has such a file, but you don't want the LSP to load its addon, there doesn't seem to be a way around this.

Currently this is just causing noisy logs for me -- I have the tapioca gem installed, and every time the Ruby LSP starts, it prints a stack trace indicating that this version constraint isn't satisfied -- but in principle I'd like to be able to configure which addons the LSP loads or doesn't load.

Description

Allow the user to configure specific addons that the Ruby LSP should load or not load, instead of unconditionally trying to load an addon for every installed gem that has a ruby_lsp/**/addon.rb file.

Implementation

To solve my immediate problem, I'd be fine with a configuration option that lets me specify a deny-list of addons that the LSP shouldn't try to load, but I can imagine a use case for only loading installed addons that occur in an explicitly-specified list.

[vinistock]

Thanks for the report. I think there's an underlying root cause here that we're missing.

If the Ruby LSP is being initialized correctly, it should compose the bundle under the .ruby-lsp directory and invoke Bundler.setup, which will limit Gem.find_files to the scope of the bundle. Even if the project has no Gemfile, this should still be working and we should not be finding globally installed gem results.

What editor are you using? Did you configure the LSP command yourself? Are you overriding BUNDLE_GEMFILE anywhere or do you have Ruby LSP related settings?

[domingo2000]

I think the feature is useful even if the scope of the gems search is the local repository. For example, in out organization there are over 250 developers, we mantain 2 custom addons, but some users don't want to use all of them.

Currently the aproach is for the addon implementer to provide a setting for enable/disable the addon based on the rubyLsp.addonSettings (example). But it should be nice if this was a standard of the core LSP to enable different developers on the same project to enable or disable addons based on custom config. Just like vscode "recommended addons" that can be enabled/disabled per user.

[vinistock]

@domingo2000 yeah, I'm not opposed to allowing add-ons being disabled. We do want to allow remembering the status of the add-on and then configuring that.

However, what @rolandcrosby-columntax is experiencing is a bug that's not related to the ability to disable/enable add-ons. That simply shouldn't happen.

[Bo98]

Not sure if it's exactly the same as the original problem but a problem we're seeing is include_project_addons is searching deep in vendor and similar directories and is causing multiple different versions of gems to be loaded. It actually causes RuboCop part of Ruby LSP to crash if it loads both pre-1.70 and post-1.70 versions.

A way to either disable include_project_addons or I guess ideally configure a list of ignored directories would be ideal (maybe even using rubyLsp.indexing.excludedPatterns though that is for indexing).