When I first started developing Python apps — mostly using Django — I took a naive and simple approach to “distribution”: I just used SVN. This worked fine while I was the only developer and had essentially two projects, an intranet site and a public site. I built all my apps in one SVN directory, checked out that directory to all my dev, test, and prod servers, and did svn updates as needed. As tends to happen, things got more complicated over time. Other folks got involved in Python/Django app development. As the number of apps increased I became more uncomfortable running all my production code off the trunk. I wanted to restructure the SVN repo so that each app could be managed more independently. And I started working on another project outside of the scope of my previous work, but for which I wanted to re-use some common code. This project had a public distribution goal, which prompted me to begin delving into Python packaging techniques. I went straight for setuptools, since I was familiar as an end-user with easy_install, and it seemed like the leading quick-and-easy solution. I happily discovered that it was, in fact, easy, and it wasn’t long before I was distributing all my apps internally as RPMs via yum and puppet. This made my sysadmin very happy.
So, that was cool, but there were a couple of problems. First, doing this kind of packaging for internal app distribution seemed like rather too much ceremony. Secondly, I realized that I really should be using virtualenv and pip, and implementing those tools totally changed the way I worked. Adding Fabric later really pulled things together for me. I established an internal package index to which I pushed sdist tarballs, and installed all my production apps into virtualenvs using pip -f. This works well, but still feels like too much overhead for internal dev-to-prod cycles.
Ironically, I find that I am now reconsidering the plain old SVN approach, with a twist. Since I am now in the habit of tagging versions, I can use some fabfile magic to switch tags and reload httpd, etc. I think, though, that what I would really like to do is use pip and editable packages installed from SVN. Unfortunately, there is not yet an option to have pip automatically switch SVN URLs (see http://bitbucket.org/ianb/pip/issue/97/need-a-way-to-install-without-prompts), which blocks my fab mojo. Now that I have experienced the benefits of packaging and have acquired the discipline of consistent versioning, I don’t want to go back to straight SVN WC’s, although that’s not a bad option, especially if you don’t need dependency management, script installation, or the other goodies you get with setuptools/pip.