There has been a lot of discussion about managing settings.py in Django. SplitSettings wiki page on code.djangoproject.com is a good summary of all sollutions that people came up with.

Importing local_settings from settings.py has become a standard in the community. This way it is possible to put settings.py under version control and keep sensitive data, like database connection parameters on a particular machine. It is only possible to override and add new parameters when using this solution. Reading and modifying default parameters in local_settings becomes a problem.

To make modifications possible, put default settings in default_settings.py and store it in version control. Users should create their local settings.py with customizations and add import at beginning:

    from default_settings import *

Now we can modify some parameters for development purposes only:

   INSTALLED_APPS += ('debug_toolbar',)

Simple change in order of imports allows us to read default configuration and add slight modifications to it. Next step would be to call a code from settings.py that would ask user for database settings. That would ease deployment of Django projects on new sites. After all settings.py is just a piece of Python.

Recently I've published venv - a tiny project available on github. It is used to manage multiple python virtual environments, just like Doug Hellman's virtualenvwrapper. Both of these tools store virtual environments in one place. Both can create, activate and remove virtual environment with one command. I did not want virtualenv to modify shell prompt, so I decided to implement my own wrapper.

Venv consists of few commands, that are pretty easy to learn. Here is the output of venv help:

$ venv help
Usage: venv COMMAND [virtualenv] [OPTIONS]
      venv virtualenv (activates virtualenv)

Available commands:
   create
   remove (rm)
   activate
   deactivate
   list (ls)
   cd
   site-packages (sp)
   ls-site-packages (lsp)

For more info type: venv help COMMAND

Venv creates all virtual environments in a special directory. By default it is ~/.venv, but it can be customized by VENV_HOME environment variable. venv create is a wrapper for virtualenv and it creates new virtualenv in VENV_HOME. venv list displays all available virtual environments.

To switch to a virtual environment called sandbox, use venv activate sandbox command, or simply venv sandbox. I didn't want virtualenv to alter my shell prompt, so I've added an option to preserve original prompt after switching virtual environments. Setting environment variable VENV_PRESERVE_PS1 to 1, will turn this feature on. Additionally venv_name variable is set to currently active virtual environment. This variable can be used to alter shell prompt instead.

Once done working on project, you may deactivate virtual environment with venv deactivate, or remove it permanently with venv remove.

Venv is pretty simple, compared to virtualenvwrapper. It does not contain hooks, that are triggered after each action and I don't plan to add them yet. It served me well for some time, so I decided to make it public. Maybe someone will find it useful too.