--use-launcher flag behavior

[robmck1995]

II'm a bit confused about the --use-launcher flag. What I am looking for is a way to start ruby-lsp without installing dependencies ALWAYS. It seems like --use-launcher will work no matter what, but when the versions do match it installs all the dependencies?

If that is right, is there any way to force dependencies NOT to be installed, even if the versions match?

[vinistock]

That flag is not intended to be user facing. We're experimenting with improvements to the server launch and the flag is used to rollout the new behaviour gradually.

By not installing dependencies, do you mean not running bundle install or not composing the Ruby LSP's bundle at all? To skip composing the bundle, you can simply run bundle exec ruby-lsp instead of using ruby-lsp. But then you have to manage the bundle yourself and the gem has to be included.

[robmck1995]

Hmm I apologize if I'm not clear as I am very new to ruby. Maybe this will help.

My use case:

• Code navigation on an arbitrary user's repo
• Clone a user's repo in a container and start up ruby-lsp on that repo.
• Startup should be quick and we should not install dependencies

The observed behavior:

• Running ruby-lsp --use-launcher with a codebase whose ruby version does not match the installed version, ruby-lsp starts up immediately (I'm assuming because the bundle install fails) BUT I still get good performance on definition/references etc
• Running ruby-lsp --use-launcher with a codebase who's ruby version does match, tries to install dependencies and takes forever to startup

I just tried bundle exec ruby-lsp but that didn't seem to work, I'm assuming because the "gem wasn't included" as you mentioned

[vinistock]

This is currently not possible and it's a combination of how the LSP works and how Bundler works. The Ruby LSP needs to be able to require gems from the application, for example your linter or formatter. Additionally, we automatically detect all application dependencies so that we can index them for go to definition, hover and so on.

Bundler does not allow gems outside of the bundle to be required. You can't boot a global executable, invoke Bundler.setup and then require any arbitrary gem. Similarly, you can't boot a global executable and require any of the application's gems without setting up the bundle.

This is why the Ruby LSP composes a separate bundle to include all dependencies that it needs. This allows us to not require users to add the ruby-lsp gem as a project dependency while still connecting to their project dependencies.

If gems are not installed, then Bundler.setup is guaranteed to fail, which is the first scenario you described. This is our degraded mode, when setting up the bundle failed. The normal mode of operation is to fully compose and install gems.

Achieving something like what you mentioned would require a new command line argument to skip taking any application dependency into account and just booting directly, but I'm concerned to add something like that as it's not what the majority of users would want. Most users want to be able to connect to their linter & formatter, jump to definitions in dependencies and discover add-ons automatically.