Closed getninjaN closed 3 weeks ago
I've got the same issue. rbenv
is loaded in .zshrc
with:
if [ -d "$HOME/.rbenv" ]; then
export PATH="$HOME/.rbenv/bin:$HOME/.rbenv/plugins/ruby-build/bin:$PATH"
if which rbenv > /dev/null; then eval "$(rbenv init - zsh)"; fi
fi
And it's working in a regular VS Code terminal window (i.e., rbenv version
returns the right Ruby version for this project).
Thank you for the bug report! We haven't changed anything related to rbenv
in a while. Did you change anything in your shell configurations recently? I'm asking because we've seen similar issues, but haven't fully understood what causes it.
And it's working in a regular VS Code terminal window (i.e., rbenv version returns the right Ruby version for this project).
This is a common source of confusion for users, which I've been struggling to make clearer. The zsh configurations working in your terminal is expected. The terminal launches the shell, which sources your configuration scripts and most of it expects to be run in a shell environment.
But when the shell is invoked outside of the context of a terminal, like we do from the VS Code code (which isn't the same process as the integrated terminal), many shell scripts fail. We've seen shell scripts that directly fail to source if certain terminal environment variables aren't set. Or others that hijack the stderr pipe and break the communication with the editor.
I think we can use a similar approach as #2791, which is now preferring known paths for the Shadowenv executable over relying that it will exist in the PATH
. That way, even if sourcing the shell scripts fails, we can still invoke the executable directly. We should probably do that for every version manager, but I'm still eager to learn what exactly causes this.
I'm not aware of any significant changes. I did update rbenv via Homebrew a while ago; the ruby version was unchanged. Of course there were some VS Code updates in the meantime. (I should note that this also fails in Cursor.)
I realize this isn't really helpful per se.
If there's anything I can provide (e.g. logs from the startup process) please let me know how to capture that.
Did you change anything in your shell configurations recently? I'm asking because we've seen similar issues, but haven't fully understood what causes it.
Not that I can remember I'm afraid. 🫤 All I have really done is update my apps and such through Homebrew.
I just noticed now while typing this at home that it's working again... 😕 But it didn't work at the office. The only difference, except for the obvious network and such, is that I'm using an external monitor there. But sounds strange that could have anything to do with it.
Well, uh... Here's my Ruby LSP Information:
1.95.1
0.8.12
0.20.1
3.1.6
rbenv
There's one thing that I noticed about another tool, namely watchman, which always stops working after being updated via Homebrew. It has to do with permissions, I think. I have to clear its caches and then it works again. Maybe an update of rbenv causes some files to be unreadable depending on a particular environment?
I opened #2824 to give the same solution we used for Shadowenv a shot. I'd still want to understand how we get into this situation, but I'm hopeful that the PR will fix the problem.
I just cut a release for v0.8.13. If you can please report back if the issue is fixed, that'd be very helpful!
I just cut a release for v0.8.13. If you can please report back if the issue is fixed, that'd be very helpful!
Seems to have been fixed. Thanks!
Indeed, it works for me as well. Thanks so much for the quick fix!
PS: Maybe I'm missing something — but I don't have shadowenv
on my system at all. Looking at the code, it would have had to be present for the discovery to work at all?
➜ brew info shadowenv
==> shadowenv: stable 3.0.3 (bottled)
Reversible directory-local environment variable manipulations
https://shopify.github.io/shadowenv/
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/s/shadowenv.rb
License: MIT
==> Dependencies
Build: rust ✔
==> Analytics
install: 147 (30 days), 256 (90 days), 1,137 (365 days)
install-on-request: 147 (30 days), 256 (90 days), 1,136 (365 days)
build-error: 0 (30 days)
PS: Maybe I'm missing something — but I don't have shadowenv on my system at all. Looking at the code, it would have had to be present for the discovery to work at all?
Shadowenv is a different version manager. It was vulnerable to the same bug as rbenv
, so I applied the same fix to rbenv
, which thankfully worked!
You don't have to install shadowenv
at all.
Does not work for me. Actually, I think it was working before
@aurelien-reeves-scalingo how did you install rbenv
and where in the system is it installed?
I forked the repo in $HOME/.rbenv
Then in my .zshrc
:
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
It worked well for months, until recently
We search only on standard installation paths. Since you can choose where to put rbenv when manually forking/cloning, we would need to search the entire file system to find it which is simply not feasible.
To account for this use case we'd need to allow configuring the executable path for rbenv
, similar to what we did for Mise and ASDF https://github.com/Shopify/ruby-lsp/pull/1914.
I'm a bit swamped, but if you'd like to put up a PR we can merge. It should be a very similar implementation.
Thanks @vinistock!
Here's a PR: https://github.com/Shopify/ruby-lsp/pull/2875
Description
Instantly when starting VSCode and extensions are starting up I get an error telling me that the rbenv command can't be found. It worked on Friday, but today it's not and I'm not sure what could be wrong. ¯\(ツ)/¯
rbenv
was installed via Homebrew and is up to date. All my extensions is up to date.Ruby LSP Information
The
Collect Ruby LSP Information for Issue Reporting
is not working. Nothing happens.Reproduction steps
Code snippet or error message