Run bundle install if Gemfile but no Gemfile.lock

[Earlopain]

Description

Reproduction steps

Check out a fresh copy of a repo with Gemfile.lock in .gitignore (rubocop/rubocop for example).

The LSP starting will first show a notice about mulitroot workspaces and after discarding that refuse to start with the following:

Project contains a Gemfile, but no Gemfile.lock. Run bundle install to lock gems and restart the server

Would it make sense to automatically run bundle install for the user in these cases? This would probably require explicit user confirmation, similarly to how VSCode asks about trusted folders. Gems may execute arbitrary commands during installation (I think, especially C extensions during compilation). Perhaps the confirmation of VSCode is already enough, if the extension isn't opting in to trusted mode, https://code.visualstudio.com/docs/editor/workspace-trust. I believe that is the case currently, however looks to be vscode specific and not part of the LSP protocol.

[andyw8]

Similarly, this also happens if you use bundle gem when creating a new gem, since there's initially no Gemfile.lock.

[vinistock]

After discussing this with the team, our general sentiment is that the LSP should not run bundle install automatically on a non-locked project. Having the bundle locked is fundamental for anything to work really. Without that, you're unable to run tests, run linters or really do much.

That said, we also believe that the experience is currently quite odd for that scenario. We are only checking if the lockfile exists and then we display a warning including information about multi-root workspaces.

We should definitely include a check to see if a Gemfile or gems.rb file exists and then we can definitely offer from the VS Code extension to first run bundle install on the project's bundle before trying to launch the language server. How does that sound?

[Earlopain]

LSP should not run bundle install automatically on a non-locked project

We should definitely include a check to see if a Gemfile or gems.rb file exists and then we can definitely offer from the VS Code extension to first run bundle install

These two seem to be in conflict unless the important part here is "automatically", as in without user interaction. Offering to run bundle install for the user sounds perfectly fine and is one possible solution I was writing about.

Right now you can open a project, ruby-lsp will show some signs of life, and then just not work. That is my main gripe I think.

[vinistock]

Yes, indeed the point of discussing was the automatic aspect. Because we actually run bundle install only for the custom bundle under .ruby-lsp, which would create .ruby-lsp/Gemfile.lock, but no top level lockfile - which can be a bit weird.

We should definitely show a message and give the chance for the user to run bundle install if desired.

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[tunacasserole]

This happens to me using neovim. My project has a gemfile.lock and it is not gitignored. This seems to be resolved by running ruby-lsp in the terminal in the project directory. I also have noticed that when I first open my project, if I open a file that is within an engine, I get the "client ruby-lsp quite with code 78". If I open a file in the root directory, it successfully kicks off the indexing and I can then navigate to an engine file and everything works fine.