Question: setup with multi Ruby install

[wta12]

I can not get solargraph works with VS code
What operating system are you using? Window 10 Edu
What version of Ruby? 2.0.0 as system path, 2.2.4 (solargraph gem installed).
What version of the vscode-solargraph extension? 0.8.0
Do you have any other extensions installed?

castwide.solargraph
donjayamanne.githistory
donjayamanne.python
formulahendry.code-runner
lei.theme-chromodynamics
magicstack.MagicPython
ms-vscode.cpptools
rebornix.Ruby

What version of the Solargraph gem? solargraph-0.12.2
Does running solargraph help return a list of commands? no
Did you change any of the Solargraph configuration settings? 

"solargraph.commandPath":"D:/SIM/script/ruby/setup/ruby22/lib/ruby/gems/2.2.0/gems/solargraph-0.12.2/bin/solargraph"

[castwide]

It looks like you're pointing at a Ruby 2.2.4 version of the Solargraph gem. Are you also running in VS Code on the Ruby 2.2.4 executable, or are you using the Ruby 2.0.0 on the system path? Version 0.12.2 of Solargraph expects Ruby 2.2.2 minimum. Earlier versions might work, but I would expect anything less than Ruby 2.1 minimum to have bugs.

If you're using RVM or something similar, you might need to make sure you're pointing to the right version of Ruby in your workspace, e.g., whatever version is listed in .ruby-version in the project's root folder. If you're using Bundler, we'll also need to make sure that's configured correctly.

If all else fails, go to Help -> Toggle Developer Tools in the VS Code menu and report any error messages you receive in the console.

[wta12]

Hi,
I am able to select ruby 2.2.4 for debug by set new configuration other than standard ruby.
i got those errors

{
        "name": "ruby_224",
        "type": "ruby",
        "request": "launch",
        "program": "${file}",
        "cwd": "${fileDirname}",
        "showDebuggerOutput": true,
        "pathToRDebugIDE": "D:/SIM/script/ruby/setup/ruby22/bin/rdebug-ide.bat",
        "env": {
        "PATH":"D:/SIM/script/ruby/setup/ruby22/bin/ruby.exe",
        "GEM_HOME": "D:/SIM/script/ruby/setup/ruby22/lib/ruby/gems/2.2.0",
        "GEM_PATH": "D:/SIM/script/ruby/setup/ruby22/lib/ruby/gems/2.2.0",
        "RUBY_VERSION": "ruby-2.2.4"}
        }

[castwide]

The error indicates that either the Solargraph gem is not installed or it couldn't be found in your Ruby environment. Can you confirm that solargraph.commandPath is correct? If you run D:/SIM/script/ruby/setup/ruby22/lib/ruby/gems/2.2.0/gems/solargraph-0.12.2/bin/solargraph from a command window, you should get a list of available commands.

If that doesn't work, based on your debug setting, the correct path might be D:/SIM/script/ruby/setup/ruby22/bin/solargraph.bat.

If neither path works but solargraph alone does, try unsetting solargraph.commandPath altogether.

[castwide]

I just discovered something else that might be causing your issue. Did you set solargraph.commandPath in the user settings or the workspace settings? When I tried to set it in the workspace settings, it got ignored, but when I set the same value in the user settings, it worked as expected.

This apparently happens because the solargraph.commandPath property has the isExecutable flag set to true (see microsoft/vscode#33439).

[zero-master]

Same issue here.

rvm 1.29.3
Linux 4.12.13-1-ARCH
/home/me/.rvm/gems/ruby-2.4.1/bin/solargraph
solargraph -v
0.13.1
vscode extension version: 0.9.1

I've not touched any configuration.

[castwide]

Are you able to install it from the command line with gem install solargraph?

[zero-master]

Successfully installed solargraph-0.13.2
Parsing documentation for solargraph-0.13.2
Installing ri documentation for solargraph-0.13.2
Done installing documentation for solargraph after 0 seconds
1 gem installed

Yes, just now tried it again but the same issue.

Each time I open VSCode, it displays the same error message as in the above screenshot.

[castwide]

I notice you're using rvm. Can you confirm that the gem is installed on the same installation of Ruby that you're using from VS Code?

If you open a folder (i.e., a workspace) in VS Code, Solargraph will use it as the current working directory for running its executables, which means it should use whatever Ruby version is specified by rvm, e.g., with a .ruby-version file.

If you only open a single file in VS Code without a workspace, it will probably use the system-level Ruby installation.

You also might want to check Help -> Toggle Developer Tools for error messages.

[castwide]

If all else fails, you can try setting your solargraph.commandPath preference to the absolute path, e.g., /home/me/.rvm/gems/ruby-2.4.1/bin/solargraph.

[zero-master]

1. Yes, I've only 1 Ruby install. No ruby install outside of rvm.
2. Yes, I've tried it both with and without a workspace. I am able to run solargraph from the VSCode integrated terminal.
3. 
4. Yep, tried that as well and removed/installed it multiple times.

It works fine on Atom.

[castwide]

Wow. I'm not sure what to make of this one, especially since it works in Atom. I haven't tested it on Arch Linux, but I know it works in CentOS.

One more possibility. Are you opening a folder that contains a Gemfile? There might be an issue if solargraph isn't bundled, but I wouldn't expect it to be a problem unless you set the solargraph.useBundler preference to true.

[zero-master]

Yes, I am using a rails project.

I tested it with/without bundler, created a new project without gemfile, it didn't help.

I even switched to login shell on VSCode as described here:
microsoft/vscode#7263

No luck.

[castwide]

Okay. Rails support is still in development, but you should still be able to use Solargraph with it. The method suggestions it gives would just be incomplete.

I'll see if I can spin up an Arch Linux VM and reproduce the problem.

[castwide]

I think I've found the problem. When you start VS Code, it runs in a shell that doesn't load your profile, so rvm doesn't get included in the environment.

I was able to make it work from a terminal window like so:

$ bash --login
$ code

Since vscode gets called from a login shell, it's able to use rvm to find ruby and run solargraph.

I'm not sure what a more permanent solution should be. I tried adding the rvm scripts to .xinitrc, but it didn't seem to have any effect.

[loicginoux]

Same issue here on v0.10.3 on Mac:
Solargraph gem not found. Run `gem install solargraph` or update your Gemfile.

I am using rvm, I tried:

• with default solarsearch settings, after having run gem install solarsearch, still having the message even if in terminal I have the command.
• installing it in gemfile and "solargraph.useBundler":true
• setting the absolute path "solargraph.commandPath": /Users/me/.rvm/gems/ruby-2.4.1@myproject/gems/solargraph-0.15.3/bin/solargraph

I couldn't make it work :(

[castwide]

I ran some tests on a MacBook. It appears that VS Code on MacOS always uses your default Ruby installation. Detailed results:

• My system Ruby installation is 2.3.3. I used rvm to install 2.4.1.
• I installed the Solargraph gem on 2.4.1 but not on system (2.3.3).
• I set the rvm default to system (rvm use system --default). VS Code did not find the gem, as expected.
• I used a .ruby-version file to select 2.4.1 in a test folder and opened the folder in VS Code. It still did not find the gem.
• I changed the rvm default to 2.4.1 (rvm use 2.4.1 --default) and reopened VS Code. This time it found the gem and code completion worked.

@loicginoux Please let me know if setting the rvm default to the desired Ruby version works (e.g.: rvm use 2.4.1 --default). I'll look into ways to make the extension more rvm-friendly.

[loicginoux]

Ok thanks it works by installing the gem on the default rvm environment.
Note that:

• reloading the window is not enough, you need to quit and reopen vscode.
• the gem does not need to be installed in the current gemset (in my case the gemset was myproject), only on default rvm env. That means that on the terminal, in my project directory, I don't have access to the commande solargraph, only via the editor.

Thank you for the response, that solves my issue 👍

[castwide]

Good to know, thanks.

I noticed a potential for disparity between the version of Ruby that runs in VS Code's integrated terminal and the version it uses for background processes. Most likely it's because the terminal uses bash and the process uses sh. Very similar to the issue with Arch Linux earlier in this thread. I'll try to find a fix for it.

[castwide]

It turns out there's a terminal workaround on Mac as well. First you have to add the code command to your path so you can launch it from the command line. From https://code.visualstudio.com/docs/setup/mac:

1. Launch VS Code.
2. Open the Command Palette (Command+Shift+P) and type 'shell command' to find the Shell Command: Install 'code' command in PATH command.

Open a terminal, cd to the folder you want to open, and run code . (note the period). VS Code should use your rvm settings for the Ruby environment. It correctly used the folder's .ruby-version file in my tests.

[zero-master]

Today when I enabled this extension, it magically started working on its own.

The only change, I've made to my environment is moving all paths from .zshrc to .zprofile

I am not using any special workaround. Let me know if you've any questions.

Edit: Forgot to notice, that the vscode extension is now: 0.10.3. Earlier in this thread it was 0.9.1, so that explains it.

[castwide]

Thanks, @zero-master. How are you opening VS Code? I just tested 1.19.0 on Arch Linux with Ruby 2.4.1 installed via rvm and no Ruby system install. When I open VS Code from the menu, it doesn't find Ruby. When I open it with the code command in a terminal, it works. Setting the rvm export path in .profile, .zshrc, or .zprofile did not have any effect.

[zero-master]

I am opening vscode using the icon launcher.

I've this in my vscode user settings:

`"terminal.integrated.shell.linux": "/usr/bin/zsh",

"terminal.integrated.shellArgs.linux": [
"-l"
],`

The second line in the config. uses login shell in the terminal. (rvm requires it)

In .zprofile:

export PATH="$PATH:$HOME/.rvm/bin"

In .zlogin:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

This setup works very well for me.

[castwide]

Version 0.11.3 of the extension uses an explicit bash shell to run Ruby processes. This should fix the issues people have been having with multi Ruby installs. It was able to find the Ruby installation configured by RVM in my tests on OSX and Arch Linux.

[bergmannf]

I was actually debugging why my current setup was not working:
I am using rbenv and zsh and I am not setting any rbenv specific settings in .bashrc or .bash_profile, so obviously the gem could not be found.

Maybe it would make sense to use process.env.SHELL as default shell and fallback to bash if that is not set?

[castwide]

@bergmannf That could work. I'll look into it.

[castwide]

vscode-solargraph v0.12.0 will use the current shell if available. In my tests, it was able to detect the Ruby installation from either bash or zsh on Arch Linux.

[castwide]

@nscmnto What OS are you using?

[posthardcode]

macOS Sierra 10.13.4 — Bruno Nascimento On Sun, Apr 29, 2018 at 20:53, Fred Snyder <notifications@github.com> wrote: @nscmnto [https://github.com/nscmnto] What OS are you using? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [#12 (comment)] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AHwzphZXiK6e1ZkdhpYeJfHUYw33TDcXks5tthomgaJpZM4PiGuW] .

[castwide]

Version 0.18.0 might fix this issue. It changes how the extension starts Ruby processes under zsh.

[DanaHolt]

I had this issue running VS Code on Windows using WSL with rvm for Rails development.

It kept telling me the solargraph gem is not installed even though it was in WSL.

So, I noticed the error message is showing Windows paths.

Then it dawned on me that it is trying to run solargraph from the Windows command line, not WSL bash.

I installed Ruby in Windows via RubyInstaller, then installed solargraph using the Windows command line.

Works like a charm now, hope this helps!

[ctsstc]

Awesome this looks to be working for me on Mac running Ruby v1.9.3p551 for my workspace settings:

{
  "solargraph.commandPath": "/Users/codyswartz/.rvm/gems/ruby-2.5.1/bin/solargraph",
  "solargraph.bundlerPath": "/Users/codyswartz/.rvm/gems/ruby-2.5.1/bin/bundle"
}

[castwide]

Extension 0.20.0 should finally resolve a longtime issue with rvm/rbenv. If you open a folder with a .ruby-version file, the language server should start with the correct version. Common workarounds for it, like starting VS Code from a terminal or customizing the solargraph.commandPath setting, should no longer be necessary. This should also resolve discrepancies between Ruby versions used by the language server and the integrated terminal.

You can check which version of Ruby you're using by running "Solargraph: Get environment info" from the command palette.

[arroadie]

thanks for the effort!

[bsrz]

I tried pretty much every options in this thread, along with options in other issues... still can't get solargraph to work.
Setting the commandPath doesn't work at all. I have a pretty clean environment and am using rbenv with Ruby 2.6.3, solargraph 0.34.2, extension version 0.20.0.
Every solargraph command in the extension fails with some variation of this:

[castwide]

@bsarrazin You might get that error if you try to run the command before the server is finished initializing. The status bar at the bottom left should give you a message that changes from "Starting the Solargraph language server" to "Solargraph is ready." Time to initialize can vary depending on the size of the workspace.

Extensions are activated on demand, so the server might not start until you open a Ruby file.

[bsrz]

@castwide is there a way to see progress/logs while the server is starting? I see "Starging the Solargraph language server ..." in the status bar, but it never completes.
How long should I expect the server to take to be ready? As I'm typing this, I opened a Ruby file and I see it starting for almost 1-2 mins now... is that expected/normal?
How can I help debug this?

[castwide]

One thing you can try is going to your workspace's root folder in a terminal and running solargraph scan -v. It'll index your workspace and dump information about it. If it throws an exception or freezes, there might be a bug in Solargraph's code analysis. More information: https://solargraph.org/guides/scanning-workspaces

Some additional tips that might help you improve performance: https://solargraph.org/guides/performance

[bsrz]

hmm I don't have a workspace, I'm using it for scripts in an iOS project.
this was working before without workspaces, is having a workspace a requirement now?

[castwide]

No. If you don't have a workspace, it should still work with individual Ruby files.

Is it possible you're opening a folder in VS Code, e.g., your home directory or Documents folder, and Solargraph is treating it as a workspace?

[bsrz]

I normally open the root of the repo by running $ code . at the command line.
I tried opening a ruby file directly and I'm seeing the same problem. I ran solargraph scan -v and tried again and still seeing the problem.
fwiw, it took 2.97secs to scan the whole repo...

Solargraph is treating it as a workspace

how can I tell?

EDIT:
I created an explicit workspace and still seeing the issue.

[castwide]

how can I tell?

Solargraph will try to treat nearly any open folder as a workspace. I might tweak this behavior in a future version, to avoid problems with the precise use case of opening a folder that doesn't represent a discrete app or library.

At any rate, it doesn't sound like the workspace is the problem here.

I just tested on a MacBook using RVM. The first time I opened VS Code, the server hung while initializing, but now I'm not able to reproduce it. No idea what the root cause is.

[bsrz]

@castwide is there anything I can do to provide debug info? logs?

[castwide]

You've been looking in all the right places, especially the developer console. You can try setting the solargraph.logLevel preference to debug, but in this particular case, it might not tell you anything. I suspect initialization is getting stuck in an infinite loop for some reason.

One other thing you can do is check Activity Monitor to see if there are zombie server processes.

[bsrz]

checking for processes:

$ ps -ef | grep solar
  501  1089     1   0  9:34AM ??         0:32.95 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  1300     1   0  9:35AM ??         0:31.89 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  2704     1   0  9:44AM ??         0:29.47 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  3357     1   0  9:47AM ??         0:28.50 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  3739     1   0  9:49AM ??         0:27.56 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  4444     1   0  9:53AM ??         0:26.94 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501  9324     1   0 10:29AM ??         0:16.49 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501 17914     1   0 10:58AM ??         0:09.85 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501 18441     1   0 10:59AM ??         0:09.77 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501 18664     1   0 11:02AM ??         0:08.45 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501 19124     1   0 11:02AM ??         0:08.19 /Users/ben/.rbenv/versions/2.6.3/bin/ruby /Users/ben/.rbenv/versions/2.6.3/bin/solargraph socket --port 0
  501 25894 57489   0 11:32AM ttys001    0:00.00 grep --color solar

after killing all of them, tried restarting VS Code and am getting the same issue, with a single process this time

[castwide]

I still haven't been able to reproduce this issue consistently. I updated to Ruby 2.6.3 and it still worked. The server hasn't hung since the first attempt.

Another long shot: you could try setting the solargraph.transport preference to stdio, in case it's a network interface issue.

[bsrz]

I tried both socket and stdio, disconnected from VPN, turned off MicroSnitch network filtering...
Still the same issue... :(

[castwide]

Sorry, I'm stumped. One last possibility, if you haven't tried it, is uninstalling and reinstalling both the gem and the extension. I'd much prefer to know what the root cause is, but a couple other users have reported solving unexplained problems that way, so it's worth a shot.

[bsrz]

Thanks for your help/patience @castwide. I tried to uninstall the extension (worked fine) and tried to remove the gem, but it gave me weird error, something about permissions. I'll save you the back and forth, but basically, something was really off/weird with my Ruby installation. I couldn't uninstall 2.6.3 without sudo. I ended up reinstalling 2.6.3 properly and reinstalling the gem and the extension.

All is working now. So there's definitely something weird that happened with permissions recently.
Not sure if it's something that can be added to the extension?
Something like "oh looks like you don't have the right perms, have you tried formatting your computer lately? 😛"

haha, anyway, thanks for you help! Really appreciate it!

[castwide]

Glad you got it working! I don't know if that kind of problem can be detected from the extension, but at least I can muck around with permissions to see if I can reproduce it.

[kaymach]

Hi @castwide. I'm having issues with solargraph playing with vscode-insiders. I've looked up everything on the internet about this issue including this thread but nothing matches my exact issue. VScode refuses to look at rbenv version of ruby and it's gem's. It keeps defaulting to the system versions.

Hopefully that image helps. I discovered this because I would always get a popup on startup of vscode to update solargraph, but it fails since it tries to update the /var/lib/gems/2.5.0 directory which returns a file permission error. I already have the latest gem installed via rbenv in my home directory, so it's a bit puzzling. I've tried the commandpath option and even installing this in full on windows 10 side, but none of that worked.

Running ruby -v and solargraph -v in vscode in bash returns the right stuff, but doesn't in SH. I'm kind of new to all this, so I'm a bit in over my head at this point. The language server runs (although a bit slow) so everything technically works. I'd just like to get it running on the latest versions of ruby and solar.

Thank you!

[castwide]

I just ran into a problem where the integrated terminal did not find the correct Ruby version, even though Solargraph did:

[user@machine workspace]$ cat .ruby-version
ruby-2.3.0
[user@machine workspace]$ ruby -v
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]

Apparently VS Code does not set your workspace as the cwd. Explicitly moving to the directory fixed it:

[user@machine workspace]$ cd .
[user@machine workspace]$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]

A more permanent workaround is to to customize the integrated shell settings:

"terminal.integrated.shell.linux": "/bin/bash",
"terminal.integrated.shellArgs.linux": [
    "--login"
],
"terminal.integrated.inheritEnv": false

The last setting tells the terminal not to inherit environment variables from VS Code.

[castwide]

@kaymach It looks like you're using WSL? The extension update released this week might give you better results with remote workspaces. More information: https://code.visualstudio.com/docs/remote/wsl

[kaymach]

@castwide Thank you for the reply. I updated WSL remote and vscode and now everything works 100%. Good thing I went on vacation at the right time instead of poking at it for 2 weeks to no avail.