Menu
A Ruby virtual environment With Ruby, this is accomplished with the rbenv utility and these rbenv plugins: rbenv-gem-rehash, rbenv-gemset, ruby-build. With that in place we can specify a local directory to contain any gems we want to install as dependencies of the project or application.
These are almost completely interchangeable, the difference being that virtualenv supports older python versions and has a few more minor unique features, while venv is in the standard library.
The main difference between the two is that conda is a bit more full featured/”magic”. Conda has dedicated syntax for creating environments and installing packages, and can also manage installing different versions of python too. For virtualenv, you just activate the environment and then use all the normal commands.
Virtualenvwrapper is a utility on top of virtualenv that adds a bunch of utilities that allow the environment folders to be created at a single place, instead of spreading around everywhere.
RVM works closer to how virtualenv works since it lets you sandbox different ruby versions and their gems, etc.
Neither sandbox, RVM, nor rbenv manage the versions of your app's gem dependencies. The tool for that is bundler.
bundle install to install explicit versions of these dependencies into an isolated locationbundle exec to run your applicationNo one seems to have mentioned rbenv.
I'll mention the way I do this with Bundler (which I use with RVM - RVM to manage the rubies and a default set of global gems, Bundler to handle project specific gems)
bundler install --binstubs --path vendor
Running this command in the root of a project will install the gems listed from your Gemfile, put the libs in ./vendor, and any executables in ./bin and all requires (if you use bundle console or the Bundler requires) will reference these exes and libs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With