Simple automation of virtualenv creation

Working with python/django related things is a great fun if we're talking about actual development. But there's a couple of things around you have to keep in mind and manage manually. One of the most annoying thing you have to do is activating different virtual environments.

I have a few projects on my local machine, most of them have separate virtualenvs, so when you have to move from one project to another you have to deactivate one, activate other and only then start working. When I was starting developing I thought it's not a big deal - only two commands actually. But after a tens of switches you're starting to get angry. Solution for that was found on Max Klymyshyn blog. There's only one thing to mention - on Ubuntu I placed Max's code at $HOME/.bashrc, because Ubuntu doesn't respect .bash_profile.

But during last weekend I decided to try a couple of projects from github. And for everyone of them I had to create separate virtual environment (and as I'm so lazy I made it automatically started). While creating a new virtualenv, I thought that this whole procedure deserves a bit of automatization too. So I made a little bash script, that creates new clean virtual environment in a new directory. Here's a script:

#!/bin/bash
if [ $1 ]
then
     echo 'Making new dir' $1
    mkdir $1
    cd $1

    echo 'Creating new dev environment'
    virtualenv .env --no-site-packages
    echo VIRTUALENV_PATH=`pwd`/.env > .venv
else
    echo 'Parameter is required for dir name'
fi

It only checks that you've specified a name for a new directory, where virtualenv is going to be created. I put it to $HOME/bin/newenv file, and chmod +x newenv to make it runnable. So now every time I want to try something new from github I have to type only one command, that creates a great place for experiments, which virtualenv is activated right when I cd into this directory.

At last, I tweaked (in russian) my bash prompt. Now it shows if current dir is svn/hg/git repo, and if so, show the name of current branch and if it has not committed changes. It looks geeky as hell, but not so informative and usefull as I expected :) It slows down using of terminal (cause it runs all svn, hg and git twice after every command on terminal: first to get a branch name, and second - for status). And it takes a half of command line space. So, there's more cons then pros, but I'll see, maybe I'll get used to it so wouldn't be able to remove it.

Testing Google App Engine application

There was a time when I did no testing at all. (As The Kooks sing "You're so naive"). And Spycify was started and achieved it's first releases with about 0 tests. Those first versions were working, but had a whole bunch of annoying bugs. The only way I had is to do massive refactoring of whole app.

Previos versions were checked manually. I started a devserver, clicked through changed parts to see does it works. Sometimes this would not help and I had to upload app to production to test it there, manually, of course. Massive refactoring was a nice chance to start using automate testing. No more manual clicking and repeating myself.

Spycify them all!

Recently I've launched my first site, that was revealed to some friends whose critisism I'm not afraid of :). It is called Spycify, and was made just for fun using Python, Google App Engine and some outside APIs.

Actually I saw facedetection API on Programmable Web, and decided that I should do something with it. There was no doubt on selecting programming language. It is Python for sure. As a hosting/framework I've chosen Google App Engine. I see it as a free place for little experiments. I know my service wouldn't need any highscalability, performancability or other cool-abilities. This is just a good place to host a little project, fast to code, fast to deploy. I know that if I place my service on GAE it will be there forever some forseeable future, so I can come back to it, if I want to and show it. There's no need to think about hosting, domain name or something like this - it "just works".