4

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 :-)

guettli
  • 25,042
  • 81
  • 346
  • 663
  • I will do it (accept an answer), but I going to wait some days. Maybe someone can tell me why I could use virtualenv. Up to now I see no reason. – guettli Feb 23 '12 at 20:00
  • Added new details to answer the question do I need a virtualenv? – Matt Alcock Feb 23 '12 at 20:50

3 Answers3

4

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.

Matt Alcock
  • 12,399
  • 14
  • 45
  • 61
  • Dear Matt, the intersting chapters in the python guide like "Structure is the key" are empty. – guettli Feb 23 '12 at 11:30
  • Agreed, it's an evolving document. I'd recommend a settings.py file for each environment and one pip file for all envs to ensure consistent dependencies. – Matt Alcock Feb 23 '12 at 11:40
3

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.

Gary van der Merwe
  • 9,134
  • 3
  • 49
  • 80
  • Yes, creating a virtualenv is quicker. But up to now this is not a problem for me. I don't set up new systems daily. And if I would, this could be automated. Separate operating system users give me a feeling of security. One system can't kill the processes and can't delete files of an other system. – guettli Feb 23 '12 at 11:51
1

Some things that you get with virtualenv that you don't get with the user or home schemes:

  1. 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).

  2. 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.

Burhan Khalid
  • 169,990
  • 18
  • 245
  • 284
  • For me, a site is like a project. This means, every site has a different $HOME and can have a different django version. Django is installed in $HOME. – guettli Feb 23 '12 at 11:34
  • Freezing environments sounds good. Never used it. But that's a pip command. I guess it can be used without a virtualenv. The docs says nothing about the requirenment of a virtual environment: http://www.pip-installer.org/en/latest/requirements.html#freezing-requirements – guettli Feb 23 '12 at 11:37
  • I use the same settings.py file for every stage. There is my variable SYSTEM (example: fooapp_customerx_d). The database name and database user are use this variable. And there is a variable called STAGE. There are some if-statements. Example: add django-debugtoolbar for dev systems. – guettli Feb 23 '12 at 12:44