Ruby Equivalent of Virtualenv

Ruby equivalent of virtualenv?

RVM works closer to how virtualenv works since it lets you sandbox different ruby versions and their gems, etc.

Does ruby have something similar to buildout or virtualenv?

There are several projects trying to handle this issue:

rip
bundler
rvm via gemsets
sandbox

Is VirtualEnv for Python essentially the same as RVM for Ruby

At the basics, they are very similar: they provide a mean for you to have a "jailed" environment with the libraries you need in your project without installing them in the "host" environment.

RVM however provides something called gemsets which I think doesn't have an equivalent in Virtualenv (the idea of grouping a set of libraries under a common name).

Also, there's some integration with the shell you can do with RVM (called RVMRC files) so that when you change directory to a RVM-based project, it will auto-load the right version of ruby and the libraries for your project.

Python use virtualenv to prevent library version conflicts. How ruby does it?

bundler is generally used to lock dependency versions for a project (e.g. the gem versions). rbenv and rvm (there are several others too) are two common approaches to managing multiple versions of Ruby. A feature these provide (at least rvm does) is gemsets: these are a way to isolate your gem directories (so you may have a default gemset and a edge gemset or something; I don't find these very useful so I apologize for the bad examples).

In general bundler is usually seen as the "good enough" solution to isolating dependencies and gemsets don't seem to be used all that often anymore.

Why do we only talk about virtual environment in python?

In fact we do talk about virtual environments in other languages. Here are some examples:

Java: Is there anything like VirtualEnv for Java?
C++: Is there an equivalent of python's virtualenv for C/C++ programs?
Javascript: is there an virtual environment for node.js?
Perl: How can I install specialized environments for different Perl applications?
Ruby: Ruby equivalent of virtualenv?
Go: Is there something like virtualenv for go? - Reddit
Haskell: Is there a notion of virtualenv in Haskell? - Quora

Does php have an equivalent to python's virtualenv or ruby's sandbox?

Assuming that you are using mod_php, there is no way to load multiple different versions into the same Apache instance. You can run multiple different versions if you're running PHP as CGI or FastCGI, but this will itself introduce some differences in behavior from mod_php.

python make virtualenv with specific python version fails

You need to specify the actual python executable name... e.g. virtualenv -p /usr/local/bin/python2.7 py2.7 or virtualenv -p /usr/local/bin/python3 py3, not the directory. Both should work on OS X with the Homebrew-installed versions of Python, fwiw...

python: what's the difference between pythonbrew and virtualenv?

Pythonbrew is akin to Ruby's rvm: It's a shell function that allows you to:

Build one or more complete self-contained versions of Python, each stored locally
under your home directory. You can build multiple versions of Python this way.
Switch between the versions of Python easily.

The Pythons you build are completely isolated from each other, and from whatever version(s) of Python are installed system-wide.

Virtualenv is similar, but not quite the same. It creates a Python virtual environment that, conceptually, sits on top of some existing Python installation (usually the system-wide one, but not always). By default, on Unix platforms (and the Mac), it creates symbolic links to the various Python library modules, so you're literally sharing those modules with the "real" underlying Python implementation. But, virtualenv has its own "bin" directory and "site-packages" directory. Anything extra you install in the Python virtual environment is only available within that environment.

One advantage to Pythonbrew is that the Python environments it creates are truly, and completely, self-contained. They cannot be contaminated by anything that gets screwed up in an underlying base Python install, because there isn't an underlying base install. This is not true of virtualenv environments. If you create a virtualenv Python, and then you somehow screw up the base Python instance it sits above (e.g., accidentally deleting part of the base Python's "site" directory while logged in as root), you'll screw up any virtualenv environment based on that Python, too.

However, virtualenv has its own advantages. Probably the biggest advantage is that it is lightweight. Since Pythonbrew compiles Python from scratch, to create one of its environments, creating a Pythonbrew Python environment takes some time. By comparison, creating a virtualenv Python environment is really fast.

You can, in fact, use them together. Here's one situation where you might want to do that.

Your base system uses Python 2.6.
You need to install Python 2.7.
For whatever reason, you can't (or don't want to) install Python 2.7 system wide,
side-by-side with Python 2.6.

In such a case, you could use Pythonbrew to install a base Python 2.7 under your home directory, where it doesn't conflict with anything installed elsewhere. Then, you can create one or more lightweight virtualenv Python environments that are based on your Pythonbrew-installed 2.7 Python. For instance, you could use virtualenv to spin up short-lived test environments for Python 2.7 that way.

I doubt most people actually do that. (I don't.) But there's no reason you can't.

Ruby Equivalent of Virtualenv