I spent 9 hours yesterday trying to figure out why my debugger and console wouldn't work correctly from within Rubymine. I was able to correct it by downgrading to Rubymine 2016.3.
Here's the issue:
Rubymine 2017.1 and 2017.2.1 both detect and cache copies of the USER gemset (correct). Yet then Rubymine appears to use the system gemset (wrong) when executing commands. This seems to potentially indicate that commands are being run as sudo, therefore being given the incorrect gemset.
This leads to a situation where you have all the correct gems installed on your remote development machine and yet when trying to run tests, the debugger, or a console, you receive an error message that you're missing gems. If you allow it to install the missing gems for you, it installs them to the gemset visible with "sudo gem env" not the user gemset at "gem env" which it should be using.
- Windows 10 Professional x64
- Remote Interpreter: Ubuntu 12.4 running latest RVM, latest RubyGems, latest Bundler; on virutal machine with Vagrant.
- Ruby version 2.3.1
Bug is present in Rubymine 2017.1 and 2017.2.1. Tried latest, not fixed. Bug is present whether or not the remote interpreter is selected via SSH or by Vagrant plugin. This is especially surprising; shouldn't it use the SSH user's gemset?
- Use Rubymine 2017.2.1
- Add remote interpreter with Ubuntu, Ruby, RVM, RubyGems, and Bundler. In my case a Rails application. I also happen to be using Vagrant. (Make sure to select the rvm gemset folder as is required when using an rvm-powered ruby machine as a remote interpreter)
- Let remote interpreter cache all the gems as expected.
- Attempt to run a test, debugger, or console. Receive a gem missing error.
On 2016.3, this does not happen. Everything works correctly.
- Failed workaround: Manually defining $GEM_HOME and $GEM_PATH in environment variables in rubymine for the debugger / test configs.
- Failed workaround: Removing all RVM gemsets and forcing a global gemset.
- Failed workaround: Run commands from the context of "bundle exec".
- You can see the correct gemset information with "gem env" on your remote machine terminal. You can see the one which Rubymine is attempting to use by doing "sudo gem env". Here you can see the incorrect folder and gems that Rubymine is using.
- I tried digging around in the XML settings for the gemset (gemmanger.xml) and noticed at the bottom of the xml file, the locations for the gemset were correct. Yet Rubymine doesn't use this when executing commands.
Feel free to ask any questions or let me know if something has changed in the 2017 editions that I'm not aware of. This appears to be a bug since it works fine in the 2016.3 version but is broken in 2017.1 and 2017.2.1. Otherwise it's unexpected behavior and the new correct way of setting up remote interpreters should be better documented.