Possible Bundler lock problem

[andyw8]

A couple of times recently, running bundle on the command line has been hanging for me.

I spotted notices this issue, and found that killing off all the active Ruby processes on my machine solved the problem, so it seems something was indeed locking the update.

When it happens again, I can investigate more to try find the culprit.

cc @bdewater

[Earlopain]

I ran into this, though I somewhat doubt it is related to the original issue. When bisecting, the gemfile.lock consistently changes and when it contains a few native extensions ruby-lsp tries to install/compile those, otherwise blocking bundler from doing its thing. Eventually the lock gets released when the install finishes, though it is highly annoying.

[andyw8]

Interesting. I wonder if we should detect if there's a bisect in progress, and avoid running Bundler if so.

[vinistock]

If the Ruby LSP is already running bundle install, it indeed makes it impossible to run another bundle install process in the command line due to the lock. Honestly, I think that's the right behaviour since we wouldn't want two processes trying to compile and install the same gems.

That said, we should improve the Ruby LSP's bundle install reporting so that instead of just printing to STDERR, we show a progress notification (similar to indexing) with the current state of bundle install.

[Earlopain]

A progress notification like that would be pretty nice to show whats going on a bit more prominently. It makes sense for bundler to not trip over itself but having to wait a minute for gems to finish compiling (gemfile specific of course) before you can continue bisecting is 😐