We work with these Technologies + Partners
Occasionally, when using a Ruby environment switching tool, such as RVM, you will discover a need to switch back to system Ruby for various reasons. Unfortunately, getting Bundler to automatically play nice with the rest of the system is not well documented. I hope this post helps to remedy that.
I recently ran into an issue with conflicting system and RVM Ruby gem sets. I was attempting to use Vagrant to run libvirt containers on a Fedora 29 system. If I had been able to only use the native system Ruby, this would not have been an issue. However, I routinely need to test various parts of my codebase using different versions of Ruby and therefore generally run inside of an RVM stack.
As you may guess, the native Ruby gems didn’t combine well with the RVM-installed Ruby when running Vagrant so I attempted to drop down to system Ruby by running rvm use system. This worked well but I hit a snag when Bundler wanted to only update the system gems to the required versions for my project. That would break quite a few other components on the underlying system.
I knew that I could always just set BUNDLE_PATH manually when switching to system Ruby but I also knew that I would inevitably forget to do that at some point. I would also need to unset BUNDLE_PATH when switching back to an RVM-managed Ruby to prevent environment corruption.
After a bit of digging, I found a solution that proved to be relatively straightforward for this particular use case. To provide seamless switching of the BUNDLE_PATH when migrating from system Ruby to an RVM-managed Ruby, simply add the code below to $HOME/.rvm/hooks/after_use_system and make it executable by running chmod +x $HOME/.rvm/hooks/after_use_system.
#!/usr/bin/env bash
if [[ "${rvm_ruby_string}" = 'system' ]]; then
# Handle the case where we are switching to system ruby
export BUNDLE_PATH="${HOME}/.bundle/system_cache"
else
# Reset in all other cases (RVM managed)
unset BUNDLE_PATH
fi
Hopefully, this helps others find a resolution to this problem. I’ll definitely remember it the next time I reinstall RVM!
Trevor has worked in a variety of IT fields over the last
decade, including systems engineering, operating system
automation, security engineering, and various levels of
development.
At OP his responsibilities include maintaining overall
technical oversight for Onyx Point solutions, providing
technical leadership and mentorship to the DevOps teams. He is
also responsible for leading OP’s solutions and intellectual
property development efforts, setting the technical focus of
the company, and managing OP products and related services. In
this regard, he oversees product development and delivery as
well as developing the strategic roadmap for OP’s product line.
At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles