Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When starting SolarGraph, try to respect project-specific installation #5109

Closed
1 task done
maxbrunsfeld opened this issue Nov 23, 2022 · 8 comments · Fixed by #15110
Closed
1 task done

When starting SolarGraph, try to respect project-specific installation #5109

maxbrunsfeld opened this issue Nov 23, 2022 · 8 comments · Fixed by #15110
Labels
enhancement [core label] language An umbrella label for all programming languages syntax behaviors ruby Ruby programming language support

Comments

@maxbrunsfeld
Copy link
Collaborator

Check for existing issues

  • 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

@maxbrunsfeld maxbrunsfeld added enhancement [core label] triage Maintainer needs to classify the issue labels Nov 23, 2022
@JosephTLyons JosephTLyons added go Go programming language support language An umbrella label for all programming languages syntax behaviors and removed triage Maintainer needs to classify the issue labels Nov 25, 2022
@mlh758
Copy link

mlh758 commented Dec 7, 2022

Wouldn't the label be Ruby instead of Go?

@ForLoveOfCats ForLoveOfCats added ruby Ruby programming language support and removed go Go programming language support labels Dec 7, 2022
@sriranggd
Copy link

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?

#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
Copy link

@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
Copy link
Contributor

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
Copy link

@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
Copy link

@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?

@JosephTLyons JosephTLyons transferred this issue from zed-industries/community Jan 24, 2024
@alexandreh92
Copy link

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
Copy link

m0n9oose commented Feb 22, 2024

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

notpeter pushed a commit to zed-extensions/ruby that referenced this issue Oct 11, 2024
…zed#15110)

Hello, this pull request adds support for specifying and using the
"binary" settings for Rubocop and Solargraph LSPs. AFAIK, Ruby LSP does
not require the bundler context but that could be added later easily.

In Ruby world, like in Node.js world, almost all
projects rely on project specific packages (gems) and their versions.
Solargraph and Rubocop gems are usually installed as project
dependencies. Attempting to use global installation of them fail in most
cases due to incompatible or missing dependencies (gems).

To avoid that, Ruby engineers have the `bundler`
gem that provides the `exec` command. This command executes the given
command in the context of the bundle.

This pull request adds support for pulling the `binary` settings to use
them in starting both LSPs. For instance, to start the Solargraph gem in
the context of the bundler, the end user must configure the binary
settings in the folder-specific settings file like so:

```json
{
  "lsp": {
    "solargraph": {
      "binary": {
        "path": "/Users/vslobodin/Development/festivatica/bin/rubocop"
      }
    }
  }
}
```

The `path` key must be an absolute path to the `binstub` of the
`solargraph` gem. The same applies to the "rubocop" gem. Side note but
it would be awesome to use Zed specific environment variables to make
this a bit easier. For instance, we could use the `ZED_WORKTREE_ROOT`
environment variable:

```json
{
  "lsp": {
    "solargraph": {
      "binary": {
        "path": "${ZED_WORKTREE_ROOT}/bin/rubocop"
      }
    }
  }
}
```

But this is out of the scope of this pull request. The code is a bit
messy and repeatable in some places, I am happy to improve it here or
later.

References:
- https://bundler.io/v2.4/man/bundle-exec.1.html
- https://solargraph.org/guides/troubleshooting
- https://bundler.io/v2.5/man/bundle-binstubs.1.html

This pull request is based on these two pull requests:

- zed-industries/zed#14655
- zed-industries/zed#15001

Closes zed-industries/zed#5109.

Release Notes:

- N/A

---------

Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement [core label] language An umbrella label for all programming languages syntax behaviors ruby Ruby programming language support
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants