Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am new to python and I am planning to learn django. I had a bit of experience with ruby (not rails) and I am familiar with RVM however I don’t understand the difference between pythonbrew and virtualenv. I know pythonbrew is a mimic of RVM but I thought virtualenv is already doing what RVM does (or vice versa that pythonbrew is already doing what RVM does). Can someone please explain and perhaps provide some concrete examples/usages to help me understand it. Thanks very much!
Pythonbrew is akin to Ruby’s rvm: It’s a shell function that allows you to:
under your home directory. You can build multiple versions of Python this way.
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.
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.