Environnement de développement Django
Pour m'assurer d'avoir, pour chaque projet, un environnement de développement qui colle au maximum à l'environnement du serveur de production, j'utilise pythonbrew et buildout-versions. Pythonbrew me permet d'installer plusieurs versions de python sur mon poste et de choisir celle qui est installée sur le serveur de production. Buildout-versions prend en note automatiquement les versions de tous les paquets installés par buildout, ce qui m'assure que les mêmes versions seront utilisées en développement, en test et en production.
Il est aussi à noter que pythonbrew crée une installation de python complètement séparée de l'installation python du système, ce qui offre une couche d'isolation pour chaque version de python. Buildout crée une deuxième couche d'isolation: chaque projet peut installer et utiliser des versions différentes des paquets python. Il est donc inutile d'ajouter une autre couche d'isolation avec virtualenv lorsqu'on utilise déjà pythonbrew et buildout.
Paquets Ubuntu requis
Il est préférable de d'abord installer libssl-dev pour pouvoir compiler python avec du support SSL.
aptitude install libssl-dev
Utilisation de pythonbrew
Les instructions d'installation sont sur le site web de pythonbrew.
Une fois pythonbrew installé, on voudra au minimum installer la version 2.6.6 qui est la version de python installée sur les serveurs de prod:
pythonbrew install 2.6.6 pythonbrew switch 2.6.6
Utilisation de buildout-versions
Pour utiliser buildout-versions, on crée d'abord un fichier versions.cfg, qu'on enregistre dans le dépôt git, et on déplace la section [versions] du fichier buildout.cfg dans ce fichier:
[versions] Django = 1.3.1 South = 0.7.3 ...
On ajoute ensuite ceci au fichier buildout.cfg:
[buildout] extends = versions.cfg extensions = buildout-versions buildout_versions_file = versions.cfg versions = versions ...
On voudra probablement aussi enlever la ligne newest = False s'il y a lieu, puisque toutes les versions seront dorénavant fixées.
Au prochain buildout, buildout-versions écrira dans versions.cfg les versions de tous les paquets installés pour le projet, y compris les dépendances. Puisque buildout.cfg inclut versions.cfg, ça aura pour effet de fixer ces versions.
Plus tard, si on veut changer la version d'un paquet, on peut aller modifier la ligne correspondante dans versions.cfg. On pourra aussi simplement effacer la ligne pour aller récupérer la version la plus récente du paquet. Buildout-versions se chargera de fixer cette nouvelle version au prochain buildout.
Certains paquets python sont installés sur les serveurs de production comme des paquets Debian. On peut vouloir les utiliser, en particulier lorsque l'installation du paquet nécéssite un compilateur C, indisponible sur les serveurs de production. Pour ce faire, il suffit de fixer la version du paquet à la version installée sur le serveur de production.
Voici une liste (à compléter) des versions installées sur les serveurs de prod (Debian Squeeze):
[versions] # Versions installées sur le serveur de prod MySQL-python = 1.2.2 lxml = 2.2.8 Django = 1.2.3 South = 0.7 docutils = 0.7 PIL = 1.1.7 pisa = 3.0.32 pysqlite = 2.6.0 ...
Petit problème: buildout est incapable d'installer MySQL-python 1.2.2 parce que le lien sur PyPI est brisé. On peut régler ce problème en installant MySQL-python 1.2.2 directement dans l'environnement pythonbrew:
pip install http://downloads.sourceforge.net/project/mysql-python/mysql-python/1.2.2/MySQL-python-1.2.2.tar.gz
Fichiers statiques
Lorsqu'on fait évoluer un site web, il est préférable de s'assurer que l'utilisateur a bien la dernière version des fichiers statiques (css, js, images) et non une ancienne version qu'il aurait en cache. Pour ce faire, j'utilisais auparavant django-compressor qui a pour objectif de compresser les fichiers javascript et css, mais qui sert aussi à faire du "cache busting". J'ai cependant eu certains problèmes avec cette app récemment, ce qui m'a permis de découvrir que Django 1.4 avait une nouvelle fonctionnalité de "cache busting".