GemNotFoundException when using solargraph as a Ruby LSP #187
Comments
|
Hey not sure if you intentionally closed this immediately for future travelers to find or if it was by accident. To be honest I have no idea how RubyGems works under the hood - I just tried on one of my systems and it seems to set a |
|
I'm also a noob in how Ruby and RubyGems are handled, so I'm really not sure if is there a way to improve. Honestly, I opened (and closed) the issue mostly to share a solution with other |
|
Thank you for sharing your solution. I faced the same issue (using |
|
Do you have any ideas how this can be dealt with? To me it sounds like the package manager is hardcoding the full executable path of whatever Ruby version is currently active? Is there any specific reason it's doing so? |
|
Can an interface be provided to run commands with LspInstaller env? Not even in the background, a Right now I'm seeing a similar issue, with gem environment set for LSP server not having anything to actually be a useful server. Easily fixed with |
This likely won't work by default. See williamboman/nvim-lsp-installer#187 (comment)
Hmm what's the use case? This would otherwise be fairly easy to accomplish, either as a core capability or through the existing APIs (e.g., through a custom command that makes use of the |
My use caseSolargraph - likely depending on configuration, I hadn't dug too deep here - needs to load at least a portion of application gems in order to work. Additionally, access to lsp-installer environment is quite useful for installing solargraph plugins. Ruby versionsNative extensions might not work across different ruby versions. This can be remedied by adding ruby version to gem-based servers' For every application and every ruby version, users will need to install their gems multiple times: once for application itself, once for every language server. But as something that can be automated with a little Lua or Vimscript, it doesn't bother me. |
|
The answer from @Slotos was the missing piece for me as well, if it wasn't clear for anyone else reading you can just do: In your application directory, and it will make sure those application specific gems are in the place there lsp installer puts solargraph. Could we get this documented in some way? Or does anyone have any ideas to get around having to do this? |
|
Yeah this will have to be fixed. I don't do Ruby dev so I'm not entirely sure what the best solution would be. One easy thing to fix is to not completely overwrite |
|
The simplest approach would be to simply use the system's way of working with gems, and let the user deal with it. coc-solargraph does exactly that and simplicity never bothered me. I personally would be content with the following behaviour:
The idea is to deliberately keep things stupid simple, so that If anything goes wrong, I'd drop down to the shell and deal with gems troubleshooting there, knowing that my editor would follow suit. |
|
I'm struggling a bit to repro this. Does anyone have a step by step description on how to reproduce this (a dummy repo would be really nice)? |
|
I just configured Solargraph on VS Code and am trying to use my newly gained knowledge from getting it working in that editor to make it work in my NeoVim setup. Solargraph usually needs to run using I'm very new to NeoVim and LSP so I'm struggling to understand how the language server is configured. i.e. is there an equivalent setting to I would be happy to create a dummy repo that replicates my working Solargraph setup in a simple Rails app. Would that help any? |
|
Fresh rails project is sufficient for reproduction gem install rails
rails new lsp-install-ruby-187
cd repro
nvim config/application.rbThis is my lsp-installer config vim.lsp.set_log_level("debug")
local lsp_installer = require("nvim-lsp-installer")
-- Register a handler that will be called for all installed servers.
-- Alternatively, you may also register handlers on specific server instances instead (see example below).
lsp_installer.on_server_ready(function(server)
local opts = {
on_attach = on_attach,
capabilities = capabilities,
}
if server.name == "solargraph" then
opts.filetypes = { "ruby" }
opts.flags = { debounce_text_changes = 150, }
opts.settings = {
solargraph = {
diagnostics = true,
formatting = true,
}
}
end
server:setup(opts)
end)Tailing Running Aside from this, a case for solargraph plugins can be explored by creating ---
include:
- "**/*.rb"
exclude:
- spec/**/*
- test/**/*
- vendor/**/*
- ".bundle/**/*"
require: []
domains: []
reporters:
- rubocop
- require_not_found
formatter:
rubocop:
cops: safe
except: []
only: []
extra_args: []
require_paths: []
plugins:
- solargraph-rails
max_files: 0Restarting solargraph with this configuration will yield the following message: One needs to run If lsp-installer avoids sandboxing, all these issues are automagically resolved. Switching environments - a common occurrence - will require a fresh solargraph install, which is why an install-on-encounter feature would be a useful QoL addition. |
|
If there was a |
|
Solargraph is not guaranteed to be checked into a Gemfile. It's designed not to require it. Granted, it's not a bad idea to have |
|
Option to run solargraph via |
|
For those applications having Solargraph already integrated using Bundler (i.e. in the |
|
Hi, there I faced the same issue due to -- from
vim.fn.jobstart("bundle info solargraph", { on_exit
-- to
vim.fn.jobstart("cat Gemfile | grep solargraph", { on_exit = ...so completely working configuration for lunar_vim looks like this: -- bundle exec solargraph stdio if Gemfile contains solargraph
vim.list_extend(lvim.lsp.automatic_configuration.skipped_servers, { "solargraph" })
local solargraph_cmd = function()
local ret_code = nil
local jid = vim.fn.jobstart("cat Gemfile | grep solargraph", { on_exit = function(_, data) ret_code = data end })
vim.fn.jobwait({ jid }, 5000)
if ret_code == 0 then
return { "bundle", "exec", "solargraph", "stdio" }
end
return { "solargraph", "stdio" }
end
local opts = {
cmd = solargraph_cmd()
}
require("lvim.lsp.manager").setup("solargraph", opts)
|
|
I've tried Slotos's suggestion, but I'm still unable to get solargraph to load the solargraph-rails plugin. I've confirmed the solargraph-rails gem is physically located in the same GEM_PATH as the nvim lsp_server's solargraph gem. At this point I'm not sure what else to try. Does anyone have any other ideas? |
|
@AlanWarren solargraph-rails is too restrictive in its solargraph version dependency - iftheshoefritz/solargraph-rails#41. It does seem that there was a reason for that, but that's fixed. Find the gem files and apply the change to it, you'll see it load. Aside from that, switch to mason.nvim and macon-lspconfig.nvim. The latter adds mason installation to gem environment variables instead of replacing them. |
|
fantastic! Thanks so much for sharing. |
I ran into an issue where Ruby LSP with
solargraphwas working and then, suddenly, it was failing with in~/.cache/nvim/lsp.log:That was awkward since:
After a while, I could figure out what has happened — so I’m registering this issue here just in case someone stumbles at the it too!
Context
:LspInstall solargraphcreates a binary at~/.local/share/nvim/lsp_servers/solargraph/bin— this is a Ruby file with a shebang. In my case, that pointed to#!/opt/rubies/2.7.2/bin/ruby. I’m not sure whynvim -lsp-installerused that particular Ruby version, but my guess is that it might be thePATHhandling done bychroot(the tool I use to handle different Ruby versions locally).I don't remember in which project/directory I first run
:LspInstall solargraph, so I’m not sure what version of Ruby the Gem was installed into.TLDR
I just got the path from the
~/.local/share/nvim/lsp_servers/solargraph/bin's shebang and installedsolargraphGem there. In my case::!/opt/rubies/2.7.2/bin/gem install solargraphThe text was updated successfully, but these errors were encountered: