Django : Which approach is better [ virtualenv + pip ] vs [manually carrying packages in svn]?

Question

I have a django project that uses a lot of 3rd party apps, so wanted to decide out of the two approaches to manage my situation :

1. I can use [ virtualenv + pip ] along with pip freeze as requirements file to manage my project dependencies.

   I don't have to worry about the apps, but can't have that committed with my code to svn.

2. I can have a lib folder in my svn structure and have my apps sit there and add that to sys.path

This way, my dependencies can be committed to svn, but I have to manage sys.path

Which way should I proceed ?

What are the pros and cons of each approach ?

Update:

Method1 Disadvantage : Difficult to work with appengine.

Answer 1

So this is what I'm using currently.

All projects will have virtualenv directory at the project root. We name it as .env and ignore it in vcs. The first thing dev did when to start doing development is to initialize this virtualenv and install all requirements specified in requirements.txt file. I prefer having virtualenv inside project dir so that it obvious to developer rather than having it in some other place such as $HOME/.virtualenv and then doing source $HOME/virtualenv/project_name/bin/activate to activate the environment. Instead developer interact with the virtualenv by invoking the env executable directly from project root, such as:-

.env/bin/python
.env/bin/python manage.py runserver

To deploy, we have a fabric script that will first export our project directory together with the .env directory into a tarball, then copy the tarball to live server, untar it deployment dir and do some other tasks like restarting the server etc. When we untar the tarball on live server, the fabric script make sure to run virtualenv once again so that all the shebang path in .env/bin get fixed. This mean we don't have to reinstall dependencies again on live server. The fabric workflow for deployment will look like:-

fab create_release:1.1 # create release-1.1.tar.gz
fab deploy:1.1 # copy release-1.1.tar.gz to live server and do the deployment tasks
fab deploy:1.1,reset_env=1 # same as above but recreate virtualenv and re-install all dependencies
fab deploy:1.1,update_pkg=1 # only reinstall deps but do not destroy previous virtualenv like above

We also do not install project src into virtualenv using setup.py but instead add path to it to sys.path. So when deploying under mod_wsgi, we have to specify 2 paths in our vhost config for mod_wsgi, something like:-

WSGIDaemonProcess project1 user=joe group=joe processes=1 threads=25 python-path=/path/to/project1/.env/lib/python2.6/site-packages:/path/to/project1/src

In short:

1. We still use pip+virtualenv to manage dependencies.
2. We don't have to reinstall requirements when deploying.
3. We have to maintain path into sys.path a bit.

Answer 2

Virtualenv and pip are fantastic for working on multiple django projects on one machine. However, if you only have one project that you are editing, it is not necessary to use virtualenv.

Answer 3

This has been unanswered question (at least to me) so far. There're some discussion on this recently:-

https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE

Ian Bicking said this in the comment:-

I do think we can do something that incorporates both systems. I posted a recipe for handling this earlier, for instance (I suppose I should clean it up and repost it). You can handle libraries in a very similar way in Python, while still using the tools we have to manage those libraries. You can do that, but it's not at all obvious how to do that, so people tend to rely on things like reinstalling packages at deploy time.

http://tarekziade.wordpress.com/2012/02/10/defining-a-wsgi-app-deployment-standard/

The first approach seem the most common among python devs. When I first started doing development in Django, it feels a bit weird since when doing PHP, it quite common to check third party lib into the project repo but as Ian Bicking said in the linked post, PHP style deployment leaves out thing such non-portable library. You don't want to package things such as mysqldb or PIL into your project which better being handled by tools like Pip or distribute.