Le petit coin de Nicolas

Aide mémoire pour la confection d'un atelier logiciel autour de Python. Il sera complété au fur et à mesure...

Pré-requis :

• pip ; un sudo easy_install pip doit fonctionner si setuptools est installé.

Installation de Virtualenv & Virtualenvwrapper

Virtualenv permet de créer des environnements virtuels python avec les librairies de votre choix. Vous pouvez avoir un environnement virtuel pour chaque version de DJango (dj-096, dj-100, dj-110, dj-120, etc) et contre lesquels vous allez pouvoir tester l'application que vous développez. L'autre avantage est que l'on peut installer ce que l'on veut comme librairie python, sans avoir de droit système. De mémoire, on doit même pouvoir utiliser plusieurs versions de python si besoin. Bref, l'idéal pour des tests et ne pas pourrir son système global

Virtualenvwrapper est l'outil pour les fainéants qui utilisent virtualenv puisqu'il simplifie l'utilisation de virtualenv. Il y a des options assez sioux ; se reporter à la documentation

sudo pip install virtualenv virtualenvwrapper

Dans votre fichier $HOME/.bashrc :

# Création du répertoire accueillant les environnements virtuels
export WORKON_HOME=$HOME/python/virtualenv
# Instructions spécifiques pour l'usage de PIP
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true
# Chargement des commandes fournies par virtualenvwrapper 
. /usr/bin/virtualenvwrapper.sh

Ensuite dans votre console :

# Création du répertoire accueillant les environnements virtuels
mkdir -p $HOME/python/virtualenv
# Prise en compte des modifications réalisées précédemments
source $HOME/.bashrc

avec pour résultat :

virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/initialize
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/premkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postmkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/prermvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postrmvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postactivate

Création de son premier environnement virtuel

mkvirtualenv demo
New python executable in demo/bin/python
Installing setuptools............done.
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postactivate

Sur votre prompt, vous devez voir un petit (demo) apparaître indiquant que vous utilisez cet environnement :

Avant :

[nsteinmetz@citrouille ~]$

Après :

(demo)[nsteinmetz@citrouille ~]$ 

Comme tout projet doit avoir sa documentation et être versionné, installons sphinx et mercurial.

pip install sphinx mercurial

Il ne vous reste plus qu'à installer les autres librairies dont vous avez besoin.

Pour sortir de votre environnement, il suffit d'utiliser la commande deactivate.

Pour revenir dans votre environnement, il faut utiliser la commande workon :

• Si vous n'avez qu'un environnement virtuel (comme dans notre cas) alors vous basculez automatiquement dans cet environnement
• Si vous avez plusieurs environnements virtuels, alors workon liste les environnements disponibles. Pour en activer un en particulier, il faut préciser son nom ; dans notre cas workon demo.

To be continued... et je suis preneur de vos retours / idées / ...

Dans le cadre des relations "One to many" ou "Many to Many", il est possible de présenter un sous-ensemble de votre modèle en fonction de critères de tri.

Codant une application de gestion de reverse proxys pour les sites web Vélos en libre service, il me faut gérer différents types d'url (une url publique, une url pour les abonnements, une url d'admin, les déclinaisons linguistiques et autres alias en tous genre) et ce pour chaque type d'environnement (VABF, PREPROD, PROD). J'aurais pu créer autant de modèles que j'ai de type d'url mais cela aurait été particulièrement contre-productif. J'ai donc un modèle unique avec les paramètres "type d'url" et "environnement". Dès lors, quand je définis les urls d'une ville, il me suffit de faire des relations "One to Many" ou "Many to many" vers mon objet Url.

Cela donne grosso modo la chose suivante pour l'objet Url:

 python
class Url(models.Model):
    """
    Url description
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    URL_CHOICES = (
        ('1', 'www'),
        ('2', 'subscription'),
        ('3', 'admin'),
        ('4', 'secondary'),
        ('5', 'translation'),        
    )
    name = models.CharField("DNS", help_text="Provide url of the site without http(s)://", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the url", blank=True, max_length=100)
    url = models.URLField("URL", help_text="Provide url of the site *with* http(s)://", verify_exists=False)
    urltype = models.CharField("URL Type", help_text="What kind of url it is ?", max_length=20, choices=URL_CHOICES)
    envt = models.CharField("Environement", help_text="In which environment is used this url ?", max_length=100, choices=ENVT_CHOICES)
    
    def __unicode__(self):
        return self.name

Dans un premier temps, la classe Town est assez simple à monter :

 python
class Town(models.Model):
    """
    Town
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    STATE_CHOICES = (
        ('1', 'On construction'),
        ('2', 'On maintenance'),
        ('3', 'Open'),
        ('4', 'Closed'),
    )
    name = models.CharField(help_text="Provide the name of the town", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the town", blank=True, max_length=100)
    prod_status = models.CharField("PROD status", help_text="State of the site on PROD environment", max_length=20, choices=STATE_CHOICES)
    prod_www = models.ForeignKey(Url, verbose_name="WWW Public URL", help_text="Public url of the site like www.velib.paris.fr", related_name="prod_www")
    prod_abo = models.ForeignKey(Url, verbose_name="Subscription URL", help_text="HTTPS URL used for all sensible process like subscribption, my account, etc. Is often like https://abo-<town>.cyclocity.fr", related_name="prod_abo",)
    prod_admin = models.ManyToManyField(Url, verbose_name="Internal administration URL(s)", help_text="URL used to access back-office", related_name="prod_admin") 
    prod_other = models.ManyToManyField(Url, verbose_name="Other URL(s)", help_text="Other urls related to the site like aliases related to the public url", related_name="prod_other", blank=True)
    prod_translation = models.ManyToManyField(Url, verbose_name="Translations URL", help_text="If site has translated versions, their public urls are listed here" ,related_name="prod_translation", blank=True)    

Cette modélisation, bien que remplissant le besoin a un désavantage certain : tous les objets de type Url sont présentés. Si on part sur 17 villes * 3 environnements * 3 urls "publiques" à minima, soit pas moins de 153 urls disponibles. Pas simple de s'y retrouver (et encore je vous dis pas tout, il y en a bien plus en fait )

Il faut alors être en mesure pour l'attribut prod_www de ne présenter que les urls de type "www" et pour l'environnement "prod".

Cela est possible très simplement grâce au filtre limit_choices_to qui adopte la syntaxe suivante :

 python
class Example(models.Model):
    foo = models.ForeignKey(<Modèle>, limit_choices_to = {'<attribut du modèle en question>': "<valeur>"}

Ce qui dans mon cas donne pour filtrer sur le type d'url et l'environnement :

 python
class Town(models.Model):
    """
    Town
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    STATE_CHOICES = (
        ('1', 'On construction'),
        ('2', 'On maintenance'),
        ('3', 'Open'),
        ('4', 'Closed'),
    )
    name = models.CharField(help_text="Provide the name of the town", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the town", blank=True, max_length=100)
    prod_status = models.CharField("PROD status", help_text="State of the site on PROD environment", max_length=20, choices=STATE_CHOICES)
    prod_www = models.ForeignKey(Url, verbose_name="WWW Public URL", help_text="Public url of the site like www.velib.paris.fr", related_name="prod_www", limit_choices_to = {'urltype': 1, 'envt': 3})
    prod_abo = models.ForeignKey(Url, verbose_name="Subscription URL", help_text="HTTPS URL used for all sensible process like subscribption, my account, etc. Is often like https://abo-<town>.cyclocity.fr", related_name="prod_abo", limit_choices_to = {'urltype': 2, 'envt': 3})
    prod_admin = models.ManyToManyField(Url, verbose_name="Internal administration URL(s)", help_text="URL used to access back-office", related_name="prod_admin", limit_choices_to = {'urltype': 3, 'envt': 3} ) 
    prod_other = models.ManyToManyField(Url, verbose_name="Other URL(s)", help_text="Other urls related to the site like aliases related to the public url", related_name="prod_other", limit_choices_to = {'urltype': 4, 'envt': 3}, blank=True)
    prod_translation = models.ManyToManyField(Url, verbose_name="Translations URL", help_text="If site has translated versions, their public urls are listed here" ,related_name="prod_translation", limit_choices_to = {'urltype': 5, 'envt': 3}, blank=True)    

Comme le montre l'exemple de la documentation, ce filtre marche aussi de façon dynamique ou bien avec des objets Q pour les requêtes complexes :

 python
    limit_choices_to = {'pub_date__lte': datetime.now}

Du coup, le formulaire de création/édition d'une ville ne me présente plus qu'un nombre réduit d'urls pour un champ donné. Au pire, ma liste de choix aura un maximum d'éléments correspondant au nombre de villes déjà entrées dans le système. Il me faudrait affiner le filtre pour en plus ne présenter que les urls non déjà liées à une autre ville. Mais c'est moins évident et immédiat

En espérant que cela puisse être utile à d'autres...

L'AFPy (Association Francophone Python - http://www.afpy.org/ ) organise le week-end du 30/31 mai à la Vilette la 3ème version de Pycon FR (aka Conférence Python, version française).

Le programme varié et riche est disponible ici : http://pycon.fr/sessions - Il me reste encore à affiner mon programme de la journée entre les différentes conf

Pour ma part, j'y serais à coup sûr le samedi et de façon peu probable le dimanche - au plaisir de vous y retrouver

En retravaillant sur Start suite au commentaire de Gilles (qui a encore disparu une nouvelle fois... ), j'avais réussi à basculer mes vues sous la forme de vues génériques mais il me restait à traiteur deux points :

• La notion de cache par vue avec l'utilisation de cache_page()
• Le contrôle d'accès aux vues avec l'utilisation de login_required().

En traitant le second point, la doc officielle de Django indiquant que pour limiter l'accès à une vue générique, il fallait faire un "wrapper" dans views.py pour y glisser le @login_required(). Un peu déçu de ce point, j'étais en train de refaire ma vue dans views.py quand David m'a indiqué ce snippet intitulé "login_required for a generic view in URLconf".

Dans la même veine et après consultation de David de du grand web, j'ai appliqué la même idée pour cache_page().

Au final, je n'ai donc plus de fichier views.py pour Start mais le fichier urls.py suivant :

 python
from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_detail
from django.views.decorators.cache import cache_page
from start.models import Theme

theme_dict = { 
    'queryset': Theme.objects.all(),
    'extra_context': { 'all_theme': Theme.objects.all().order_by("order")},
}

urlpatterns = patterns('',
    (r'^(?P<slug>[a-z0-9-]+)/$', login_required(cache_page(object_detail, 60 * 5)), theme_dict),
    (r'^$', 'django.views.generic.simple.redirect_to', {'url': Theme.objects.get(is_default=True).slug }),
)

Mon souhait est donc exaucé - reste encore celui de Bruno...

Textmate propose 2 bundles pour Django : "Python Django" & "Python Django Templates" (cf le SVN des bundles TM). Or ces deux modules étaient restés valides pour les versions 0.9x de Django. Avec l'arrivée de Django 1.0, ces modules ont donc perdu de leur intérêt suite à l'arrivée du nouveau framework de formulaires et de la nouvelle interface d'administration.

Heureusement, une petite équipe s'est mise à mettre à jour ces deux bundles, qui sont disponibles sur bitbucket.org. Pour les avoir fraîchement installés mais pas encore joué avec, j'ai quand même été agréablement surpris par leur richesse sur la partie "Admin" et "Forms" notamment.

A suivre donc...