Existing projects do not create the .ruby-lsp folder

[davideluque]

Operating System

MacOS Sonoma

Ruby version

3.1.4

Project has a bundle

• Has bundle

Ruby version manager being used

asdf

Description

The extension is installed in VSCode, but when I open other projects, the server fails to start because the .ruby-lsp folder isn't created automatically, and there isn't a command to do so.

[vinistock]

Thank you for the bug report! Can you share the exact error you're seeing? Is there anything printed to the Ruby LSP channel in the Output tab?

The .ruby-lsp folder is created automatically by the server. The only case in which it doesn't do it, is if ruby-lsp and debug are already a part of your project's Gemfile - but that's okay, it should still continue to work.

[soundnotation]

I believe I have the same bug using a different setup.

Windows 11 10.0.22621
WSL2 1.2.5.0
Ruby 3.2.2
RVM 1.29.10
Bundler 2.4.21
Ruby LSP gem 0.12.1
Ruby LSP VS Code extension 0.4.13

Following is shown in the notification area in VS Code a few seconds after starting it:

Failed to setup the bundle: Command failed: gem install ruby-lsp
ERROR: While executing gem ... (Errno::EACCES) Permission denied @ dir_s_mkdir - /home/ubuntu/.rvm/gems/ruby-3.2.2
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:406:in `mkdir'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:406:in `fu_mkdir'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:384:in `block (2 levels) in mkdir_p'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:382:in `reverse_each'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:382:in `block in mkdir_p'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:374:in `each'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/fileutils.rb:374:in `mkdir_p'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/rubygems/installer.rb:712:in `verify_gem_home'
/home/simone/.rvm/rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/rubygems/installer.rb:903:in `pre_instal...

Running the command gem install ruby-lsp in my project directory doesn't give any errors, but I have the gem already in my Gemfile anyway: gem 'ruby-lsp', '>= 0.11.2'. I also have the debug gem.
I have only this project open in VS Code, although I have other RoR projects in my home. No trace of the .ruby-lsp folder.

[soundnotation]

Also posted here. Not sure which place is best.

[vinistock]

@davideluque is this problem still happening? If so, can you share the contents of the Output tab?

[scheals]

This issue seems to be preventing me and many others from using Ruby-LSP "out of the box".

I first encountered the issue of Ruby-LSP plain not working (stuck on Ruby LSP: Starting, no output at all, silence on all frequencies) on WSL2 Ubuntu - I figured that perhaps since the extension is so fresh there's some WSL2 jank stopping it from working. Back to my Xubuntu 22 VM I went and to my surprise - the exact same issue. By now, I've encountered three other users that have the same exact issue - they migrate from now deprecated extensions and they're left with nothing, without any clue to what's happening. Thankfully, I think I believe I have identified the culprit.

The Setup

A fresh VirtualBox 7 Xubuntu 22.04 install:

• VSCode
• Git
• Node installed with nvm
• Ruby 3.2.2 installed with rbenv
• Ruby LSP and VSCode rdbg Ruby Debugger extensions

The Trouble

First, I checked whether an old project of mine will work "out of the box", so I cloned my Connect Four repo and opened it with code .. Ruby LSP Output tab is silent, extension's notifications in {} are stuck in the various starting states like "Ruby LSP: Starting" and such. Take note that this project lacks:

• Gemfile
• Gemfile.lock
• .ruby-version

.ruby-lsp is never created - I've checked with ls -a.

Second, I figured let's just do a fresh run. I created a new directory, opened VSCode with code ., created a Ruby file with junk like:

# testing
two = 1 + 1
p two
sdasdasd # this error is here on purpose and is because of me testing a different issue w/ the debugger

Nothing. .ruby-lsp is nowhere to be seen. Close VSCode and open it again - maybe now it'll bite. Nope.

The Breakthrough

I believe I picked this approach by reading through various issues in this repo - manually creating stuff that should be in .ruby-lsp gets it off the ground. So that's what I did:

1. I ran bundle init. No dice.
2. I added ruby-lsp to the bundle.
3. Didn't budge, decided to close and reopen VSCode.
4. Success! Ruby-LSP is here, working! And so is .ruby-lsp.

The Solution

Now, I played around for a while and it all hinges on the presence of a file called Gemfile.lock. Its contents are not important, as long it's there on VSCode launch, Ruby-LSP is going to create .ruby-lsp and work more-or-less as intended (can't say it works in 100% because I don't know how it is intended to work).

This is a departure from how previous extensions have worked - they worked out of the box on any Ruby file - Gemfile.lock or no Gemfile.lock. There's some other "quirks" compared to the previous setup but I'm not sure if all of them are a Ruby-LSP problem or something else - I'll soon file an issue report for at least one thing I believe is on Ruby-LSP's end.

EDIT: Apologies, I didn't notice Shopify/vscode-ruby-lsp#945 . I assume that'll fix this.

[andyw8]

@scheals just a little advice based what you said above:

It's almost always worth adding a Gemfile.lock to each project you work on. Otherwise you have no guarantee that it will work on another machine, since the gem versions may differ. It may even stop working on your own machhine, if you happen to install a newer version of a gem.

You can learn more here: https://bundler.io/guides/getting_started.html

[scheals]

(Apologies for the off-topic but I feel like it'd be in bad taste not to respond to someone offering good advice)

@andyw8
I agree and thank you for the good advice - that project should have at least Rubocop, RSpec and a Ruby version in its Gemfile since there are config files related to them. That's something that flew over my head that long time ago I made that toy project. Most of what I've done in Ruby is toy projects, most of them employing no gems at all. When I was starting out in learning Ruby I had no idea what gems and Gemfiles are and I had no need for them - all I was doing is writing a single method in a file. The older extensions didn't mind that at all - they were happy when they saw me mucking about in an .rb file and from a comment I read in another issue, this should also be the case with Ruby-LSP:

The extension is activated on two scenarios: if there's a lockfile (bundle) or if you open a Ruby file.

From my observation, there's plenty of people that do not use bundles and come from the old extensions wondering why the new one is not working at all. If I saw someone having issues with the extension, the very first instinct of mine would be: "Let's cut off all the variables. New directory, new file, some "Hello world!" tier code, no gems, nothing fancy. Bare Ruby file." Due to Ruby-LSP not working correctly (and reporting absolutely nil) on opening a Ruby file for one reason or another, that'd be somewhat of a puzzling dead-end.

I'm very grateful for your and other maintainer's work. Ruby-LSP is an upgrade from the previous extensions and I'm excited to see it grow, so chapeau bas for taking on such an important project for Rubyists.

[github-actions]

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

[vinistock]

It's unclear to me if what @scheals has reported is exactly the same scenario as the original author's.

However, it is an issue indeed. We're currently not allowing the Ruby LSP to be used without any folders opened in VS Code (by early returning here).

The fix is not super trivial though. We will need to add some CLI flag to the server to allow it being launched bypassing the custom bundle logic and then pass that flag when there are no folders opened in VS Code.

[vinistock]

The issue mentioned by @scheals is the same as #1780. Let's please centralize discussions related to usage without workspaces there.

Regarding this original issue, it's unclear as to what exactly the problem was. We made several improvements to version manager integrations, so hopefully the problem has been solved.

If not, please let us know.