Reputation: 27139
For every project and every stage (dev, prod, ...) I use a different linux user. I can use pip and the --user
option, to install packages in $HOME.
My isolated environment comes form different linux users.
Which benefits could I get from virtualenv? Up to now, I see no reason to use virtualenv. But maybe I am missing something.
Linux user names are build like this: project_name_S and S is the stage (dev, qual, prod, testing). Each stage can be on a different host.
Update:
More than three years after asking this question: I use virtualenv now. The user-environment was buggy. Maybe it has better support now. But nothing stops you from creating a virtualenv in $HOME :-)
Upvotes: 4
Views: 4907
Reputation: 12901
Virtualenv's are great for managing dependencies. Config files (or settings files) are very good for managing variable differences between environments. (e.g db location e.tc)
The python hitchhikers guide is very good and worth a 20 min read. http://docs.python-guide.org/en/latest/index.html
See this section on virtual envs.
http://docs.python-guide.org/en/latest/dev/virtualenvs/
If you just want to use different home or env mode variables you could just set it before you run the python code.
PROD_MODE=PROD python example.py
example.py would then look for the PROD_MODE variable like so.
import os
print os.environ['PROD_MODE']
So do you need a virtualenv?
I would strongly recommend it. So you have Django working and you've imported some other libraries (i also strongly recommend pip) and everything is working on your machine. Your path is setup and your code can resolve to the code using PATH and PYTHON_PATH. Brilliant!
Now you come to deploy on another machine (maybe aws, an linux server or similar) or a fellow developer wants to help code on your project. How do they make sure the env on there machine is setup just the same as yours and how do you ensure you deploy with the same env you tested all your shinny new code with? A virtualenv does this for you! You just port or recreate the virtual env on the new machine any everything works just as tested/built.
In short a virtual env helps you ensure you don't have a headache in remembering all your imports, installs and path settings when you release/deploy code.
Upvotes: 4
Reputation: 174748
Some things that you get with virtualenv that you don't get with the user or home schemes:
Ability to use different versions of packages - for example, django stable and django dev for different sites, without polluting the system-wide Python install (or your user's python install).
Ability to freeze package requirements and easily replicate running environment. You could possibly do this with the alternate install scheme, but you would be very limited to what you can do (in terms of packages to install), you'd have to manually keep track of your requirements file.
In general, I would recommend you re-visit virtualenv for your next project.
Upvotes: 1
Reputation: 9573
Creating a virtualenv sould be quicker and easier than creating a new user. I would not recomend switching for existing projects, but consider it for new projects.
Upvotes: 3