When starting SolarGraph, try to respect project-specific installation

[maxbrunsfeld]

Check for existing issues

• [X] Completed

Is your feature request related to a problem?

If a user has multiple versions of the SolarGraph language server, Zed should use the one that's most appropriate for the current project.

Describe the solution you'd like

From this comment by @attilagyorffy

I believe Zed should ideally follow the Convention Over Configuration paradigm and be smart about the above without the need of any configuration necessary. I believe a sensible priority (from higher to lower) would be the following:

• Use the solargraph bin stub if present (./bin/solargraph)
• Use the bundled version of solargraph if specified by the bundler context (see method described above)
• Use the matching solargraph in the $PATH (which should match the version of Ruby -> This is the current implementation if I understand correctly)
• Fail with a helpful error message, and with a link to a publicly available piece that helps setting things up

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[mlh758]

Wouldn't the label be Ruby instead of Go?

[sriranggd]

Hi,

Does this issue mean that solargraph support in Zed doesn't work at all until this issue is closed? Or does this issue just refer to being smart about picking the project specific solargraph executable?

zed-industries/zed#5469 mentions solargraph should work as long as it is there in the $PATH. I have set it up like that. When I launch the terminal app (either independently or inside Zed), the shell is able to find the solargraph executable. The project root has a .solargraph.yml config file also. Despite this I do not get auto-suggestions and features like Go to definition doesn't work.

Anything I can/need to do to get it working or do I just have to wait till this issue is fixed?

[sent-hil]

@sriranggd I solved it by going into the default shell in a Zed terminal, then adding the version of Ruby I wanted in .ruby-version in root, and then installing solargraph. Then I was able to get Got to definition working.

My issue was I was using fish shell and Zed used the system shell for env, though it correctly opened fish shell when I open a terminal inside Zed.

I got rubocop to work, but it only worked when I opened the file and then never again. Gave up on it and started using rubyfmt instead.

Not sure if this is your problem, but perhaps it might be useful.

[hovsater]

I just want to chime in and say that this will automatically get sorted out whenever we expand Zed with the ability to customize what language server to use. At that point, it should be as easy as adjusting the command to run to bundle exec solargraph instead of just solargraph for your current project.

Solargraph have diagnostics and formatting off by default, but I've shared a tip of how to enable that. 🙂

[sriranggd]

@sent-hil What exactly do you mean by deafult shell in a Zed terminal ? And when you say Zed used the system shell for env - which one is that?

I am using bash and then Terminal window inside Zed also shows the same. The login shell for my user account is set to bash.

[sriranggd]

@hovsater I tried adding the config from your tip to my editor settings (both global and local) but it did not help. I do not see a solargraph process started and running. Any suggestions on what I am missing?

[alexandreh92]

Hey guys, do we have any progress on this one? I want to use it but the LSP keeps returning:

stderr: [WARN] Failed to load gems from bundle at /Users/my-user/my-project
stderr: #<Thread:0x00000001180a50c8 /Users/my-user/.rvm/gems/ruby-2.7.4/gems/solargraph-0.47.2/lib/solargraph/language_server/host/diagnoser.rb:45 run> terminated with exception (report_on_exception is true):
stderr: /Users/my-user/.rvm/gems/ruby-2.7.4/gems/rubocop-1.47.0/lib/rubocop/feature_loader.rb:46:in `rescue in rescue in load': cannot load such file -- rubocop-graphql (LoadError)

The project is using Ruby 3.1.3 and the LSP server keeps targeting 2.7.4 (default) as default in rvm.

I appreciate your work here!

[m0n9oose]

hey guys. I think I may have the same problem, but wanted to add some details. Readme says:

Zed currently doesn't install Solargraph automatically. To use Solargraph, you need to install the gem. Zed just looks for an executable called solargraph on your PATH

But i don't think this is true. I have installed solargraph with my project's Gemfile, not globally. The solargraph bin is in PATH but Zed still fails to find it, because it looks in wrong place:

2024-02-22T14:28:08+01:00 [INFO] starting language server "solargraph", path: "/Users/i/project", id: 3
2024-02-22T14:28:08+01:00 [INFO] starting language server. binary path: "solargraph", working directory: "/Users/i/project", args: ["stdio"]
2024-02-22T14:28:08+01:00 [ERROR] failed to start language server "solargraph": No such file or directory (os error 2)
2024-02-22T14:28:08+01:00 [ERROR] server stderr: Some("")
2024-02-22T14:28:08+01:00 [INFO] Validation check requested for "solargraph" but it cannot be reinstalled

$ which solargraph
/Users/i/.rvm/gems/ruby-3.2.1@project/bin/solargraph

Another thing to mention: I see that settings.json allows to set a path to lsp binary:

  "elixir": {
    // Change the LSP zed uses for elixir.
    // Note that changing this setting requires a restart of Zed
    // to take effect.
    //
    // May take 3 values:
    //  1. Use the standard ElixirLS, this is the default
    //         "lsp": "elixir_ls"
    //  2. Use the experimental NextLs
    //         "lsp": "next_ls",
    //  3. Use a language server installed locally on your machine:
    //         "lsp": {
    //           "local": {
    //             "path": "~/next-ls/bin/start",
    //             "arguments": ["--stdio"]
    //            }
    //          },
    //
    "lsp": "elixir_ls"
  }

But I believe this setting does not work for ruby.

Huge thanks to maintainers, i was looking for this kind of editor :)

Zed: v0.124.0 (Zed Preview) OS: macOS 14.3.1 Memory: 32 GiB Architecture: aarch64