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

VSCode extension + chruby custom paths via RUBIES = cannot find installation directory for Ruby #1969

Closed
swrobel opened this issue Apr 24, 2024 · 12 comments · Fixed by #2004
Closed
Assignees
Labels
bug Something isn't working

Comments

@swrobel
Copy link

swrobel commented Apr 24, 2024

Description

Reproduction steps

  1. Start VSCode in a ruby project dir. Error notification pops up.
Screenshot 2024-04-24 at 2 01 32 PM
Failed to activate [object Object] environment: Cannot find installation directory for Ruby version 3.3.1 or ruby-3.3.1

The only output that I see in the VSCode output tab for Ruby LSP is:

2024-04-24 14:10:27.958 [info] (my-app) Discovered Ruby version 3.3.1 from file:///Users/swrobel/Code/my-app/.ruby-version

I don't see an activation command that I can attempt to replicate, as suggested in the troubleshooting steps, but running chruby 3.3.1 in the VSCode terminal works without error.

Versions / Environment

  • VSCode 1.88.1
  • Ruby LSP VSCode version v0.5.19
  • Ruby LSP Gem version unknown, but I've run the Ruby LSP: Update language server gem command

VSCode settings.json

  "rubyLsp.rubyVersionManager": {
    "identifier": "chruby"
  },

.ruby-version file contents:

3.3.1

A perhaps unique aspect of my setup is that I install rubies via Homebrew, and make them available in chruby by setting the RUBIES env var in my .zprofile. This seems to be picked up properly by VSCode, regardless of whether it's launched from the dock icon or a terminal command.

$ echo $RUBIES
/opt/homebrew/Cellar/ruby/3.3.1 /opt/homebrew/Cellar/ruby@3.2/3.2.4

Another bug?

As an aside, this extension produces a confusing/inaccurate error message if using a .ruby-version file that doesn't specify a patch version, even though that should be acceptable for chruby, ex:

3.3

The error shown is:

Failed to activate [object Object] environment: No .ruby-version file was found
@swrobel swrobel added the bug Something isn't working label Apr 24, 2024
@tisba
Copy link

tisba commented Apr 27, 2024

I have the same issue, but haven't set RUBIES, I'm using plain chruby.

@vinistock
Copy link
Member

The latest version exposes the setting to configure RUBIES. I reached out to the rubygems team to verify if they had settled on the specification for the .ruby-version file. Indeed omitting the patch should be supported, so I'll try to put a PR up for that.

@swrobel
Copy link
Author

swrobel commented May 2, 2024

@vinistock, I tested the latest, and noticed that the behavior of the new config doesn't exactly match the description provided, since:

$ echo $RUBIES
/opt/homebrew/Cellar/ruby/3.3.1 /opt/homebrew/Cellar/ruby@3.2/3.2.4

But I needed to set the following in my settings.json, omitting the version numbers:

"chrubyRubies": ["/opt/homebrew/Cellar/ruby","/opt/homebrew/Cellar/ruby@3.2"]

After adjusting that, it seems like an improvement, but it's now generating a different set of errors:

Failed to setup the bundle: Command failed: gem install ruby-lsp
ERROR:  Error installing ruby-lsp:
	ERROR: Failed to build gem native extension.

    current directory: /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0/ext/prism
/opt/homebrew/opt/ruby/bin/ruby extconf.rb
checking for prism.h in /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0/include... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
	--with-opt-dir
	--with-opt-include=${opt-dir}/include
	--without-opt-include
	--with-opt-lib=${opt-dir}/lib
	--without-opt-lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/opt/homebrew/Cellar/ruby/3.3.1/bin/$(RUBY_BASE_NAME)
extconf.rb:94:in `<main>': prism.h is required (RuntimeError)

extconf failed, exit code 1

Gem files will remain installed in /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0 for inspection.
Results logged to /Users/swrobel/.gem/ruby/3.3.1/extensions/arm64-darwin-23/3.3.0/prism-0.27.0/gem_make.out
.         See [Troubleshooting](https://github.com/Shopify/ruby-lsp/blob/main/TROUBLESHOOTING.md) for help
Failed to setup the bundle: Command failed: gem install ruby-lsp
ERROR:  Error installing ruby-lsp:
	ERROR: Failed to build gem native extension.

    current directory: /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0/ext/prism
/opt/homebrew/opt/ruby/bin/ruby extconf.rb
checking for prism.h in /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0/include... yes
checking for prism/extension.h in /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0/ext... yes
checking for whether -fvisibility=hidden is accepted as CFLAGS... yes
Running make build/libprism.a with {"SOEXT"=>"dylib", "AR"=>"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar", "ARFLAGS"=>"rcu ", "MAKEDIRS"=>"mkdir -p", "RMALL"=>"rm -fr"}
make: getcwd: No such file or directory
make: *** No rule to make target `build/libprism.a'.  Stop.
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
	--with-opt-dir
	--with-opt-include=${opt-dir}/include
	--without-opt-include
	--with-opt-lib=${opt-dir}/lib
	--without-opt-lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/opt/homebrew/Cellar/ruby/3.3.1/bin/$(RUBY_BASE_NAME)
	--enable-build-debug
	--disable-build-debug
	--enable-build-minimal
	--disable-build-minimal
extconf.rb:69:in `system': Command failed with exit 2: make (RuntimeError)
	from extconf.rb:69:in `block in make'
	from extconf.rb:68:in `chdir'
	from extconf.rb:68:in `make'
	from extconf.rb:132:in `<main>'

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  /Users/swrobel/.gem/ruby/3.3.1/extensions/arm64-darwin-23/3.3.0/prism-0.27.0/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /Users/swrobel/.gem/ruby/3.3.1/gems/prism-0.27.0 for inspection.
Results logged to /Users/swrobel/.gem/ruby/3.3.1/extensions/arm64-darwin-23/3.3.0/prism-0.27.0/gem_make.out
.         See [Troubleshooting](https://github.com/Shopify/ruby-lsp/blob/main/TROUBLESHOOTING.md) for help

@vinistock
Copy link
Member

Interesting. Maybe the rubies installed via Homebrew have a different gem home than what I expect. Can you share what does gem env path print for you for both rubies? Also, if you run gem install ruby-lsp, does that successfully compile Prism or does that fail too?

@swrobel
Copy link
Author

swrobel commented May 2, 2024

Can you share what does gem env path print for you for both rubies? Also, if you run gem install ruby-lsp, does that successfully compile Prism or does that fail too?

3.3.1

$ gem env path
/Users/swrobel/.gem/ruby/3.3.1:/opt/homebrew/lib/ruby/gems/3.3.0

$ gem install ruby-lsp
Successfully installed ruby-lsp-0.16.6
1 gem installed

It seems prism was already installed on 3.3.1. With ruby-lsp installed, I no longer get any errors in VSCode when launching my Ruby 3.3.1 project.

3.2.4

$ gem env path
/Users/swrobel/.gem/ruby/3.2.4:/opt/homebrew/lib/ruby/gems/3.2.0

$ gem install ruby-lsp
Fetching language_server-protocol-3.17.0.3.gem
Fetching ruby-lsp-0.16.6.gem
Fetching prism-0.27.0.gem
Fetching sorbet-runtime-0.5.11367.gem
Successfully installed sorbet-runtime-0.5.11367
Building native extensions. This could take a while...
Successfully installed prism-0.27.0
Successfully installed language_server-protocol-3.17.0.3
Successfully installed ruby-lsp-0.16.6
4 gems installed

However, my Ruby 3.2.4 project still throws errors when opening in VSCode. Here's a gist of the ruby-lsp Output tab from VSCode.

@swrobel
Copy link
Author

swrobel commented May 3, 2024

@vinistock realizing perhaps this doesn't notify you since the issue is closed. @ing you just in case...

@vinistock
Copy link
Member

It does actually, unless I explicitly unsubscribe. I'm not sure what's going on for the older Ruby. It's breaking when running bundle install, but inside Bundler's own code. And it's the Bundler version that is vendored inside the Ruby installation.

I assume you can successfully run bundle install in your terminal, so I wonder if we're not finding the wrong Bundler executable. If you run bundle -v in your terminal for the old Ruby, which version is printed?

@swrobel
Copy link
Author

swrobel commented May 3, 2024

You're correct that there was something wrong with my Ruby 3.2.4 bundler setup. After resolving that, everything seems to be working as expected with ruby-lsp.

I suppose it's just the gem home issue outstanding at this point. Thanks so much for your help! 🚀

@vinistock
Copy link
Member

I suppose it's just the gem home issue outstanding at this point

Sorry, which gem home problem?

And my pleasure, thanks for reporting it!

@swrobel
Copy link
Author

swrobel commented May 3, 2024

Sorry, which gem home problem?

You previously said:

Interesting. Maybe the rubies installed via Homebrew have a different gem home than what I expect. Can you share what does gem env path print for you for both rubies?

and I provided those in the comment above

@vinistock
Copy link
Member

Oh, I see what you mean. Yeah, it doesn't seem like there are any issues there. Looking at the output you shared, we did find the correct gem home and gem path. So all should be good 👍.

@swrobel
Copy link
Author

swrobel commented May 3, 2024

So all should be good

If that's the case, then why did auto installation of the gem fail? It only worked after I manually installed it globally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants