Mais c’est aussi appétissant que les méduses échouées.

Donc pour se faciliter la vie, vous utilisez virtualenvwrapper.

Et bien il y a plus meilleur : pew.

Non content d’avoir un nom cool et court, c’est un progrès non négligeable dans l’ergonomie de notre vie de dresseur de reptiles.

D’abord : pip install pew.

Ensuite, tableau d’équivalence avec virtualenvwrapper :

Vous noterez que les commandes de pew sont plus faciles à retenir, plus cohérentes, et toutes des sous-commandes histoire d’éviter de pourrir son espace de nom.

Autres avantages : pew n’a pas besoin qu’on ajoute un fichier à votre .bashrc pour marcher. Car pew ne source pas un env dans votre shell courant, il ouvre un nouveau shell. Pour sortir de l’env, c’est donc un simple Ctrl + D.

Seulement ça ne s’arrête pas là. Pew possède quelques commandes bonus qui changent bien la vie :

Bon, le seul truc qui manque pour le moment, ce sont les hooks.

Ce qui va différencier le moment où vous savez programmer dans CE langage, ce sont des notions qui lui sont spécifiques et que vous commencez à maitriser.

Voici 5 notions spécifiques au langage qu’il faut apprendre en priorité si vous voulez pouvoir dire “je code en Python” :

Pip

Pip est la moyen le plus utilisé d’installer une bibliothèque externe dans l’environnement Python. Dès qu’on veut faire un projet sérieux, on en a besoin. Tellement qu’il va en fait être inclus par défaut dans Python 3.4.

Lire l’article sur pip.

Virtualenv

Virtualenv permet d’isoler plusieurs installations de Python. A partir du moment où l’on travaille sur plusieurs projets en même temps, il devient vite indispensable. Mais personnellement, je l’utilise même quand je n’ai qu’un projet installé sur une machine car il me permet de le séparer du setup Python du système et d’utiliser des hooks.

Un outil qui a été ajouté dans la lib standard en Python 3.3. J’apprécie que le pragmatisme de l’évolution de Python qui intègre petit à petit les projets qui se sont révélés les outils de facto dans la communauté.

Lire l’article sur virtualenv.

Les listes en intention

J’ai envie de dire l’itération en générale, mais c’est un très vaste sujet, et il est couvert en grande partie par les 3 derniers points.

La liste en intention, ou liste en compréhension, est une manière de boucler sur un itérable (souvent une liste), avec optionellement un filtre, afin de produire une nouvelle liste. En une ligne.

C’est stylistiquement la marque de fabrique de Python (même si c’est piqué à Haskell). C’est également ce qui le rend aussi expressif. On peut presque coder tout un programme en déclaratif avec des enchainements de listes en intention.

C’est beau, propre, efficace et court. IN-DIS-PEN-SA-BLE.

Lire l’article sur les listes en intention.

L’unpacking

L’unpacking est une autre fonctionalité typiquement pythonienne qui permet de prendre un itérable (souvent un tuple), et de mettre ses éléments dans des variables d’une traite.

Cela permet d’augmenter drastiquement la lisibilité des programmes.

Lire les articles sur l’unpacking.

Les générateurs

Les générateurs permettent non seulement un énorme gain en performance, mais en plus ils autorisent le traitement itératif de flux de données dont on ne connait pas la taille en avance, voire de taille infinie. Si vous utilisez des expressions génératrices, vous pourrez le faire en déclaratif. Si vous utilisez yield, vous pourrez cacher un algorithme complet derrière une simple boucle for.

Lire l’article sur yield.

Le reste ?

Tout le reste, c’est du détail. Les décorateurs, la POO, l’opérateur with, les métaclasses, les astuces magiques pour faire ceci ou cela. C’est bien, mais ça peut attendre. Ce sont ces 5 notions, qui, bien utilisées, feront d’un programmeur un dev Python.

J’ai vu des tas de propositions pour résoudre ça, certains à base de réinstallation sous Mac, d’autres à base d’édition de fichiers source Python sous Debian.

Personnellement j’utilise une autre solution, un peu chiante, mais beaucoup plus propre, qui consiste simplement à appeler la commande virtualenv sur le dossier qui contient l’env. Par exemple :

virtualenv ~/.virtualenvs/test

Je dis un peu chiante car :

• Si on a beaucoup d’env, il faut le faire une fois par env.
• Et si on a des options genre -p, il faut les repasser telles qu’on les a passé à l’origine (et allez vous souvenir de ça pour un env qui a 6 mois) sinon on pête l’env.

Rappel : le .bashrc c’est le fichier qui est automatiquement chargé au démarrage du shell bash, le shell par défaut sur la plupart des Unix incluant Mac et Ubuntu.

Donc si vous voulez avoir une expérience de travail personnalisée dans votre terminal, c’est dans ce fichier que ça se passe.

Personnellement, j’ai tout le bordel que met Ubuntu par défaut (notamment les trucs avec les autocomplétions de partout). En en prime je rajoute :

# un raccourcis pour lancer Redis car je le met sur off par défaut mais je le 
# lance souvent
 
function redis {
    if [ ! -e "/var/run/redis/redis-server.pid" ] ; then
        sudo service redis-server start
    fi
}
 
# un tas de raccourcis type
 
function projet_django {
    workon projet_django;
    cd /home/sam/Work/projet_django/repo/projet_django;
 
    if [[ $# -ne 0 ]]; then
        ./manage.py $@
    fi
}
alias sb='projet_django'
 
# CF: http://sametmax.com/un-alias-bash-pour-django-virtualenv-dont-je-ne-peux-plus-me-passer/
 
 
# fonction fétiche de bourrin
 
function killbill {
    BAK=$IFS
    IFS=$'\n'
    for id in $(ps aux | grep -P -i $1 | grep -v "grep" | awk '{printf $2" "; for (i=11; i<NF; i++) printf $i" "; print $NF}'); do 
        service=$(echo $id | cut -d " " -f 1)
        if [[ $2 == "-t" ]]; then
            echo $service \"$(echo $id | cut -d " " -f 2-)\" "would be killed"
        else
 
            echo $service \"$(echo $id | cut -d " " -f 2-)\" "killed"
            kill -9 $service
        fi
    done
    IFS=$BAK
}
 
# que j'ai un peu amélioré depuis http://sametmax.com/tu-vas-crever-oui/
 
 
# une fonction pour commiter rapidement 
function commit {
    git commit -m "`echo "$*" | sed -e 's/^./\U&\E/g'`"
}
alias co=commit;
 
# en gros on tappe "co message de commit". Sans guillement, sans rien.
 
# des completions pour manage.py et git
 
source /home/sam/.django_bash_completion
source /home/sam/.git-completion.bash
 
# activation du cache de pip pour éviter de télécharger 20 fois la même lib
 
PIP_DOWNLOAD_CACHE='/opt/pip-cache';
export PIP_DOWNLOAD_CACHE;
 
# un super outil pour un git plus user friendly
 
[ -s "/home/sam/.scm_breeze/scm_breeze.sh" ] && source "/home/sam/.scm_breeze/scm_breeze.sh"
alias c="git_index"
 
# j'en avais parlé ici : http://sametmax.com/scm-breeze-facilite-la-selection-de-vos-fichiers-a-commiter-sous-git-avec/
 
 
# un prompt personalisé tout en couleur
# formaté comme ça: [nom du virtualenv] sam ~/path (branche git) $
 
source ~/.prompt.bash
 
# le fichier ressemble à ça : http://0bin.net/paste/d103a91dc41818462da0c8468ddddf4141f2efd6#dKr6qWHfAVZsSnOQ7fA4pPQ3Dquhz0Oj1b2OF8xw6vA=
 
# la configuration de virtualenv wrapper 
export WORKON_HOME=/home/sam/.virtualenvs
mkdir -p $WORKON_HOME
source /usr/local/bin/virtualenvwrapper.sh
 
# plus de détails ici : http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/
 
 
# j'ai récément succombé aux sirène du virtualenv automatique
# j'avais beaucoup d'a priori (particulirement écraser la commande CD)
# mais à l'usage, c'est pratique
has_virtualenv() {
    if [ -e .venv ]; then
        workon `cat .venv`
    fi
}
venv_cd () {
    builtin cd "$@" && has_virtualenv
}
alias cd="venv_cd"
has_virtualenv
 
# en gros ça m'active un virtualenv si il y a un fichier .venv avec un nom
# de virtualenv dedans dans le dossier courrant
 
 
# je vous en parlais récement (http://sametmax.com/configurer-votre-terminal-pour-quil-vous-notifie-de-la-fin-dune-commande-longue/)
# c'est pour avoir une notifi à la fin des commandes longues 
notify_when_long_running_commands_finish_install
 
 
# ca c'est un truc de feignasse car je me souviens jamais comment extraire 
# en ligne de commande tel ou tel format
 
extract () {
    if [ -f $1 ]
    then
        case $1 in
            (*.7z) 7z x $1 ;;
            (*.lzma) unlzma $1 ;;
            (*.rar) unrar x $1 ;;
            (*.tar) tar xvf $1 ;;
            (*.tar.bz2) tar xvjf $1 ;;
            (*.bz2) bunzip2 $1 ;;
            (*.tar.gz) tar xvzf $1 ;;
            (*.gz) gunzip $1 ;;
            (*.tar.xz) tar Jxvf $1 ;;
            (*.xz) xz -d $1 ;;
            (*.tbz2) tar xvjf $1 ;;
            (*.tgz) tar xvzf $1 ;;
            (*.zip) unzip $1 ;;
            (*.Z) uncompress ;;
            (*) echo "don't know how to extract '$1'..." ;;
        esac
    else
        echo "Error: '$1' is not a valid file!"
        exit 0
    fi
}
 
# ça date de http://sametmax.com/decompresser-sous-linux-en-ligne-de-commande/
 
# et quelques alias pour des tâches de tous les jours
 
alias ..='cd ..'
alias ...='cd ../../'
alias ....='cd ../../../'
alias .....='cd ../../../../'
alias ......='cd ../../../../../'
 
alias process='ps aux | grep'
alias serve="python -c 'import SimpleHTTPServer; SimpleHTTPServer.test()'"

Le jour où ça casse, c’est le chaos.

Dans le monde de Python, la solution à ce problème est d’utiliser des environnements virtuels. Ca à l’air d’un gros mot, mais derrière ce terme se cache la notion simple d’avoir des installations de Python isolées de l’OS, et séparées les unes des autres pour chaque projet.

Il existe plusieurs écoles: certains utilisent buildout. C’est une solution puissante, et très compliquée. Python 3.3 vient avec venv, un outil intégré pour gérer les environnements virtuels. Pour les gens comme moi qui veulent quelque chose qui marche partout, tout le temps et facilement, il y a virtualenv.

Installation et usage

Première chose à faire, installer virtualenv:

pip install --user virtualenv

Si vous avez besoin d’un rappel sur pip, c’est par là.

Ensuite, pour chacun de vos projets, créez un environnement virtuel:

virtualenv /path/vers/projet/env_nom_du_projet

Virtualenv va créer un dossier avec un environnement complet dedans: l’interpreteur Python, les libs, des commandes, etc. C’est votre installation isolée.

Pour travailler dans votre installation isolée:

• sous Unix, il faut faire source /path/vers/projet/env_nom_du_projet/bin/activate.
• sous Windows, il faut faire C:\\path\vers\projet\env_nom_du_projet\Scripts\activate.bat.

Votre prompt de ligne de commande va changer pour indiquer que vous êtes dans un environnement virtuel:

(env_nom_du_projet) sam $

Si vous installez une bibliothèque avec pip, il l’installera dans cet environnement virtuel, et elle ne sera pas accessible ailleurs. Si vous lancez la commande python, le shell Python aura accès à toutes les libs de cet environnement virtuel.

Vous pouvez sortir de l’environnement virtuel avec la commande deactivate.

Creez autant de virtualenv que vous voulez: un par projet, un pour les tests de nouvelles libs, un pour le plaisir, un pour la route… Ca prend juste de la place, et ce n’est pas ce qui manque sur nos disques durs de nos jours.

Quelques astuces avec virtualenv

Isolation par rapport à l’OS

Vous pouvez choisir que votre env hérite des libs de l’OS, ou non, mais uniquement à la création. Il faut spécifier une option:

• --no-site-packages: votre environnement est vierge, il n’hérite pas des libs du système et a seulement accès aux libs standards de Python (os, sys, itertools, json, etc).
• --system-site-packages: tout ce qui est installé sur l’OS est disponible dans installé dans l’env (et sera installé à l’avenir). Par exemple sous Ubuntu, vous pourrez importer toutes les libs d’UbuntuOne, le système de synchronisation Cloud d’Ubuntu écrit en Python.

Les anciennes versions ont la valeur --system-site-packages activée par défaut, les nouvelles versions de virtualenv ont la valeur --no-site-packages activée par défaut.

Si vous utilisez --system-site-packages, vous pouvez quand même demander à pip freeze de lister uniquement les libs de l’env avec l’option --local.

Choisir une version de Python

Parfois vous voudrez utiliser une version spécifique de Python. Vous pouvez tout à fait créer un env dédié à Python 3.2 et un autre à Python 2.6, il faut juste que les deux versions soient installées sur votre système.

Je ne vais pas détailler commen installer deux versions de Python en parallèle sur chaque OS car je n’ai aucune idée de comment on fait sous Mac ou Windows, mais sous Ubuntu c’est très simple: par défaut on est en Python 2.7, et pour installer Python 3, on fait sudo apt-get install python3. Pour installer Python 2.6, on fait sudo apt-get python2.6.

On a alors 3 executables: /usr/bin/python va déclencher Python 2.7, /usr/bin/python2.6 va appeler Python 2.6, etc. Aucun conflit système, c’est merveilleux.

Il ne reste qu’à construire son environnement virtuel en lui passant en paramètre le chemin vers le Python à utiliser:

virtualenv mon_env -p /usr/bin/python2.6

Et voilà, si on active “mon_env”, la commande python ouvre un shell en Python 2.6, et toutes les libs de l’env sont en 2.6.

Attention: on ne peut pas reconvertir facilement un env d’une version de Python à l’autre. Une fois que c’est créé, c’est fait. Si vous changez d’avis, faite un pip freeze, supprimez l’env, recréé l’env, et faites un pip install -r.

Virtualenv depuis un script extérieur

Si vous êtes dans un script extérieur et que vous voulez appeler un de vos scripts avec ce virtualenv, vous n’avez pas besoin de l’activer pour que ça marche. Il suffit d’appeler le script en le passant en paramètre à l’interpréteur de l’env. Par exemple:

/path/vers/projet/env_nom_du_projet/bin/python mon_script.py

Le script sera alors exécuté dans le cadre du virtualenv.

virtualenvwrapper: ou comment ne pas se faire chier pour passer d’un env à l’autre

Si vous êtes sous Windows, vous pouvez aller boire une bière à la cuisine, ça ne marche pas sous votre OS.

Pour les chanceux qui ont accès à un Unix, il existe un merveilleux logiciel qui va vous éviter le yoyo entre les envs:

pip install --user virtualenvwrapper

Ensuite il faut rajouter quelques lignes dans votre script d’init de shell, par exemple dans ~/.bashrc:

export WORKON_HOME=~/.virtualenvs
mkdir -p $WORKON_HOME
source ~/.local/bin/virtualenvwrapper.sh

Selon où vous avez installé virtualenvwrapper, la dernière ligne peut changer. Moi, mon virtualenv est installé au niveau du système dont le chemin est plutôt /usr/local/bin/virtualenvwrapper.sh.

Ces lignes vont lancer virtualenvwrapper en permanence dans le shell. Relancez le terminal pour l’activer. Le premier lancement va vous afficher un tas de lignes, rassurez-vous, ça n’arrive qu’une fois.

Ensuite, vous avez accès à de nouvelles commandes:

• mkvirtualenv nom_env va créer un virtualenv dans le dossier ~/.virtualenvs, où que vous soyez.
• workon nom_env va automatiquement activer un env, où que vous soyez.
• rmvirtualenv nom_env va surpprimer l’env du même nom.

Les options de mkvirtualenv sont les mêmes que pour la commande virtualenv, vous n’avez juste plus à vous souciez de où sont vos envs, ni de où vous êtes.

C’est bon, on l’a viré.

En attendant, voici le mail, et la réponse (je strip l’intro et la conclusion.):

Je viens de lire le post sur virtualenv+django et je me disais qu’il existe un moyen différent, oserais-je dire plus propre (pas sur la tête pitié …), de faire quasiment la même chose.

Je m’explique : je vois dans le script l’utilisation de workon, je ne me rappelle plus trop mais je crois que cette commande est amenée par virtualenvwrapper. Dans ce cas là, je voulais vous faire partager le contenu de quelques fichiers contenu dans mon dossier .virtualenvs.

Tout d’abord le fichier postactivate (hook fourni par virtualenvwrapper s’insérant après l’initialisation de l’environnement) :

PROJECT_PATH="$PROJECT_HOME"/"$env_name"   if [ -a "$PROJECT_PATH" ] ;then cd "$PROJECT_PATH" fi

ce petit script permet de faire ce que tu décris dans le post, si jamais ton dossier contenant le projet ne se trouve pas à l’endroit défini par la variable d’environnement $PROJECT_HOME, il est possible d’overrider son comportement en modifiant PROJECT_PATH par le chemin que tu souhaite dans le fichier .virtualenvs/nom_de_l’environnement/bin/postactivate

Voili voilou et sinon pour encore me faire mousser (mais pas trop hein), je voulais juste vous faire partager un autre script que je place dans postmkproject :

echo "Create a django project y/n ?" while true do read INPUT case "$INPUT" in "y" ) cd "$PROJECT_HOME" rm -r "$envname" pip install django django-admin.py startproject "$envname" cd "$envname" break ;; "n" ) break ;; esac done

En clair, ça demande à l’utilisateur si son projet sera un projet django, ça télécharge le framework via pip et cela créé directement le projet dans notre dossier PROJECT_HOME, en évitant d’avoir à créer un autre sous-dossier rien que pour notre application django.

Bonjour l’ami,

Merci de l’info. Comme tu vois, on l’a fait passer. Quand tu as un truc comme ça à mettre, utilise les commentaires, ça en fait profiter tout le monde !

@+

Et si vous n’êtes pas racistes, vous utilisez peut être quelques tools Ruby, comme compass.

Mais du coup, gem install compass ne marche pas, il faut soit faire un sudo, soit plonger dans les méandres de rvm. Pas glop.

Petit astuce

Virtualenv wrapper vient avec des scripts qui se déclenchent à des évenements. Typiquement, env/bin/postactivate est le script déclenché après l’activation de l’env.

Mettez dedans:

export GEM_HOME="$VIRTUAL_ENV/gems"
export GEM_PATH=""
export PATH=$PATH:"$GEM_HOME/bin"

Et voilà, gem install va maintenant installer les gems dans le virtualenv.

Si vous voulez sortir de virtualenv vous pouvez utiliser la commande deactivate:

(sametmax)[max@maximus ~/work/sametmax.com] deactivate
[max@maximus ~/work/sametmax.com]

D’autres liens sur virtualenv:
– Résoudre l’erreur Python ImportError: cannot import name urandom
– Travailler moins pour gagner plus, en 15 minutes avec Python fabric