Experiences with virtualenv + Django?

144 views
Skip to first unread message

John Crawford

unread,
May 23, 2011, 10:00:43 PM5/23/11
to Django users
I'd like to know what kind of experience people have had, in using
virtualenv (to run a particular version of Python on a VPS) with
Django, and related packages? Not *just* Django (and Python), I'm
fairly sure that will work, but all the other bits and pieces that
tend to be required, like mod_wsgi, or mysqldb_python, and so on?

Is virtualenv really effective, or does it turn out to be a nightmare
to get everything working correctly? I've been looking around the web
(particularly StackOverflow), and it like more like a nightmare. :(

The VPS I am using, turns out to run on CentOS, which uses Python 2.4
for everything, alas. So either I downgrade all my existing 2.6 code
to 2.4, or I install 2.6 on the VPS without breaking it, which would
require virtualenv. (Or changing hosting, which I'm also seriously
considering...)

John C>

Eric Chamberlain

unread,
May 23, 2011, 10:12:54 PM5/23/11
to django...@googlegroups.com
We run CentOS on our servers and use virtualenv for each of our various django projects (multiple projects on one server), we haven't had any issues, but we use fastcgi between the web server and django.

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>

AJ

unread,
May 23, 2011, 11:12:56 PM5/23/11
to django...@googlegroups.com
Virtualenv is amazing. I use one virtualenv setup for a project. never had any troubles. I have shared hosting with Dreamhost.com and I run my Django apps on a virtualenv. :)
--
AJ

Ori Livneh

unread,
May 24, 2011, 1:27:05 AM5/24/11
to django...@googlegroups.com
virtualenv is good at what it does, but it's not a comprehensive deployment tool. It does one thing, and I think it does it well. A really good resource is JKM's companion repository to his Django deployment workshop, replete with slides. His setup uses Chef, but you should also check out Puppet.


I'd be a bit turned off, by the way, by a host that only offers Python 2.4 -- it'll be seven years old in November!

Stuart MacKay

unread,
May 24, 2011, 7:34:33 AM5/24/11
to django...@googlegroups.com
John,

Regarding Python 2.6 on CentOS you might find this article useful:
http://blog.milford.io/2010/06/alt-installing-python-2-6-from-source-in-centos/

I use virtualenv on a VPS running Ubuntu 10.04 LTS with Django 1.2,
django-cms and about 10 other installed apps in various combinations.
The apps are installed using pip from either the main python repository
or directly from source checked out out of github and bitbucket. To date
I have had no issues.

The only problem you might come across is when updating source code from
a repository is that any changes you make will be overwritten. So for
example to use staticfiles with django 1.3 I had to rename directories
in django-autocomplete so the javascript and css files would be found
automatically. Any time I deploy a new release and update the installed
packages using pip then I have to rename the directories again since pip
effectively does a clean install.

Regards,

Stuart MacKay
Lisbon, Portugal

Simon Connah

unread,
May 24, 2011, 8:38:09 AM5/24/11
to django...@googlegroups.com
On 24 May 2011, at 12:34, Stuart MacKay wrote:
>
> The only problem you might come across is when updating source code from a repository is that any changes you make will be overwritten. So for example to use staticfiles with django 1.3 I had to rename directories in django-autocomplete so the javascript and css files would be found automatically. Any time I deploy a new release and update the installed packages using pip then I have to rename the directories again since pip effectively does a clean install.

Fabric and a simple shell script would sort that one out. Just automate the updating of your packages with Fabric and then once all the packages have been updated, use Fabric to run your shell script (or Python script) to rename the folders as required.

Simon.

Shawn Milochik

unread,
May 24, 2011, 9:42:25 AM5/24/11
to django...@googlegroups.com
1. You can compile Python 2.6 (or 2.7) in your home directory and use
that to create your virtualenvs.

2. I do 100% of my Python work with virtualenv, and would never do
otherwise.

3. It is not a nightmare AT ALL, and is wonderful.

4. With pip install, pip freeze, and pip install -r it's super-easy to
replicate a virtualenv.

Like you, I use Cent OS with Python 2.4 installed, but all of our apps
run under Python 2.7.


Brian Bouterse

unread,
May 24, 2011, 9:53:23 AM5/24/11
to django...@googlegroups.com
Python is embedded so deeply into operating systems these days that not using virtualenv is a bad idea.  Here is what happened to me once:

1.  I went to pip intall a python package without virtualenv
2.  The installation failed leaving my python system raising an interpreter error when going to run anything python
3.  Everything on the system started breaking (yum, bash were the most noticible).
4.  I really tried to recover the box by repairing python .... installing a newer version of python .... removing and reinstalling
5.  Could not recover the linux system; it ended up being faster to rebuild it.

Don't be like me and break your system by not using virtualenv.

Brian

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.




--
Brian Bouterse
ITng Services

Shawn Milochik

unread,
May 24, 2011, 9:59:44 AM5/24/11
to django...@googlegroups.com
On 05/24/2011 09:53 AM, Brian Bouterse wrote:
> Python is embedded so deeply into operating systems these days that
> not using virtualenv is a bad idea. Here is what happened to me once:
>
> 1. I went to pip intall a python package without virtualenv
> 2. The installation failed leaving my python system raising an
> interpreter error when going to run anything python
> 3. Everything on the system started breaking (yum, bash were the most
> noticible).
> 4. I really tried to recover the box by repairing python ....
> installing a newer version of python .... removing and reinstalling
> 5. Could not recover the linux system; it ended up being faster to
> rebuild it.
>
> Don't be like me and break your system by not using virtualenv.
>
> Brian

To add to that, you can (and should) create each virtualenv with the
--no-site-packages option. That way, each virtualenv is isolated from
whatever stuff you have installed into the OS's default Python
installation. Further, I never install anything in the base Python
installation.

Not only do you get standalone virtualenvs for whatever purpose you
like, it also makes upgrading a lot easier.

And an additional side note: If you are in a place (like a VPS) where
you have root access, you should install Python2.7 with configure, make,
sudo make altinstall. The altinstall will install Python2.7 on your
system in an alternate location, leaving the default version alone so
everything else in the OS continues to work.


Andre Terra

unread,
May 24, 2011, 10:12:24 AM5/24/11
to django...@googlegroups.com
Here's my go-to reference guide to using virtualenv and pip for django development[1]. The same steps apply to deployment, to some extent.

Additionally, I recommend you checkout virtualenvwrapper[2]. It makes your life incredibly easier and switching virtualenvs becomes as simple as typing 'workon my_virtualenv'. FWIW, I think this question is so often asked that it would be reasonable to add a couple of links to these guides on djangoproject.com (which I might preemptively add is not the same as endorsing this or that solution).


Sincerely,
André Terra

John Crawford

unread,
May 24, 2011, 1:31:26 PM5/24/11
to Django users
Thanks all, great answers. Sounds like virtualenv is better than I
thought. And Shawn cleared up one of the misconceptions I had, I
didn't realize it was possible to alt-install multiple versions of
Python - I was trying to install 2.6 *under* virtualenv, which is not
how it works. :)

Still not finished yet, but have gotten to a clean 'import django'
with Python 2.6, apparently without disturbing Python 2.4 at all. :)

John C>

John Crawford

unread,
May 24, 2011, 1:36:55 PM5/24/11
to Django users
(sigh) Naturally as soon as I hit the [send] button, another question
comes up :) I switched to my VPS, and was thinking about where to
create a project, when I was wondering:

How do people generally organize their virtualenv directories, and
Django projects?

I'm on as root on my machine, and under /root, created /root/mylib
(where Python 2.6) is, and /root/myenv for the env, but thinking about
it, those may not be the best locations. :) Should they be under my
root login? Or is that a bad idea for some reason? And if so, where?

Shawn Milochik

unread,
May 24, 2011, 1:57:48 PM5/24/11
to django...@googlegroups.com
I create a folder called 'pyenv' in the root of my 'home' directory and
put all of my virtualenvs there.

I don't use the root user or the root home folder for anything, and you
probably shouldn't either.

If you're going to have multiple projects running on the same server,
here's what I do. I don't know if it's "recommended," but it works great
for me (and my company).

Separate 'home' folder for each project.

Each 'home' folder has a 'pyenv' folder. You'll only be actively
using one, but you can have multiple for testing updates to Python
modules or Python versions.

Always install and use supervisor + gunicorn, and have the Django
app run (via gunicorn) by supervisor. You'll need to tweak the
supervisor config file so that the log and PID files don't conflict, but
that's easy.

One nginx installation with separate config files for each project,
each very simple and mainly just doing a proxy_pass to the appropriate port.


If you have more questions don't hesitate.

Shawn

Reply all
Reply to author
Forward
0 new messages