Allow custom gemfile for debug

[malcolmohare]

Motivation

Potentially closes:
#1767
st0012/ruby-lsp-rspec#33

When triggering debug (run and debug) from the editor, this extension was setting the env BUNDLE_GEMFILE to be the RubyLsp generated one, not the workspaces one.

Implementation

I added a new setting, rubyLsp.debugGemfile, allowing users to specify the Gemfile to use for debug runs. This way, no users are affected by this change unless they opt in.

Automated Tests

When I try and run the tests, I get this error. So I haven't bothered to write one for this change.

AssertionError [ERR_ASSERTION]: Ruby bin path does not exist /opt/rubies/3.3.4/bin

Manual Tests

You can see this test in action by triggering debug runs from the editor. If you set the setting, you should see the value of the BUNDLE_GEMFILE change in the output of RubyLsp when it dumps all the envs into the output.

[malcolmohare]

investigating CLA status

[malcolmohare]

I have signed the CLA!

[vinistock]

Thank you for the contribution, but I don't believe this solves the problem reported in those issues.

The fact that we point to the composed bundle under .ruby-lsp shouldn't be an issue for triggering debugging because it will always include the debug gem. If it's a part of the project's bundle, it will simply not add it to .ruby-lsp/Gemfile. Otherwise, it will add it automatically to ensure it's there.

I believe the issue behind the problems reported is that the Bundler settings that we detect and adjust during booting the language server are not passed to the environment we use to launch the debugger.

If my suspicion is correct, the solution is to have the language server return the Bundler settings as part of the initialize response and then have the extension merge the settings into the Ruby object's environment, so that launching the debugger is guaranteed to use the environment we configured with the composed bundle.

[malcolmohare]

Perhaps there are multiple issues then? My specific issue was that the lockfile you are generating in the lsp directory is getting different dependency versions that my application lock file.

The RubyLsp generated lockfile does not obey the contents of my projects own lockfile. For at least the immediately problematic gem, it selected a much newer version (dry-monads 1.6.0 vs 1.3.5), which my application is not compatible with. This dependency gem is not declared in my Gemfile, its a dependency of a dependency, and the version is not specified where its declared. But either way, I would ASSUME the RubyLsp would honour my projects lockfile and not go pick its own versions.

[vinistock]

Perhaps there are multiple issues then? My specific issue was that the lockfile you are generating in the lsp directory is getting different dependency versions that my application lock file.

If that happened, then the issue is rooted elsewhere and has consequences that extend beyond debugging. The language server itself would index incorrect dependencies if that happens, which is not solved by this PR.

Our composed bundle should always be based on your project's lockfile and we only request updates for the ruby-lsp, ruby-lsp-rails and debug gems if they are not in the project's Gemfile.

Whenever the lockfile is modified or the LSP is booted, we check if the main lockfile matches exactly the same versions as when we last booted and if not, we re-generate the composed bundle to avoid mismatches.

Now, it could have gotten into a bad state due to some bug either in the LSP or in Bundler. For example, there was a recent Bundler bug where running bundle check would result in undesired modifications to the lockfile.

For ensuring that they are sync again, I'd suggest removing the entire directory and then reloading the editor/rebooting the LSP rm -r .ruby-lsp. If you still notice that you're getting different dependencies in the composed bundle vs the main one, then please report back and we can try to dig into why that is happening. We need to fix the issue at the root cause.