Mieux vaut tard que jamais j’imagine.

Dans cet article, on va voir comment lancer python depuis la ligne de commande, ainsi que les commandes qui lui sont liées: pip, venv, etc.

Sous Windows

Vous avez installé Python, c’est certain. Vous lisez votre premier tuto, qui vous dit de lancer cmd.exe, et de taper python, mais impossible de le faire marcher. Des messages du genre ‘python’ is not recognized as an internal or external command apparaissent. Ou alors le mauvais Python se lance.

Déjà, premièrement, désinstallez Python, et réinstallez-le (en utilisant l’installeur officiel si possible), mais sur la toute première fenêtre de l’installeur, vérifiez bien que la case “Add Python to PATH” (ou son équivalent français) qui est tout en bas est cochée. Sans cela, le dossier d’installation de Python ne sera pas trouvable par le shell au moment de taper la commande. Je sais, ça devrait être coché par défaut. J’ai signalé ça plusieurs fois sur la mailing-list, et ils n’en ont rien à foutre.

Le clitoris de l’installation de Python

Alternativement, si vous ne voulez pas désinstaller Python, ou si vous n’utilisez pas l’installeur de Python standard, cherchez le dossier où vous avez installé python. C’est un dossier qui doit contenir python.exe et un dossier appelé Scripts. Très souvent on le trouve à C:\users\[votre nom d'utilisateur]\Local Settings\Application Data\Programs\Python\Python36. Ajoutez ce chemin dans le sys PATH, ainsi le chemin vers le sous-dossier Scripts.

Redémarrer votre console. Vous devriez au moins pouvoir taper python -v.

Maintenant, sachez que vous ne devriez pas taper la commande python.

Whaaaaaaaaaaaaat ?

Vous entends-je me hurler suavement à l’oreille.

Non. Sous Windows, vous devriez utiliser la commande py -X.Y. La commande py permet en effet de spécifier la version de Python à lancer. Par exemple py -2.7 pour lancer Python 2.7, ou py -3.6 pour lancer Python 3.6, s’ils sont installés sur la machine, bien entendu.

Pourquoi utiliser la commande py ? Et bien parce que sinon, python lancera le premier python.exe qu’il trouve. Si vous avez plusieurs versions de Python installées sur votre machine, ce qui est souvent le cas sur les machines de dev, des fois à son insu, vous allez avoir des problèmes.

En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez py -X.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon.

Aussi, rien à voir, mais n’utilisez pas les terminaux de cmd.exe ou powershell.exe. Ils sont à chier. Prenez le temps de télécharger cmder, et si vous le pouvez, faites le cmder.exe /REGISTER ALL en admin tant que vous y êtes.

Aussi petite astuce bien pratique: si vous maintenez shift et que vous faites un clic droit dans l’explorateur de fichier ou sur le bureau, un menu contextuel différent de celui habituel s’ouvre. Il contient des actions fort utiles:

• “Ouvrir fenêtre de commande ici”, qui vous ouvrira la console, immédiatement dans le bon dossier.
• “Copier en tant que chemin d’accès”, qui vous permettra de mettre le chemin de n’importe quel fichier dans le presse-papier.

Sous Unix (Max, Linux, etc)

N’utilisez pas la commande python, mais utilisez une commande suffixée pythonX.Y. Par exemple, pour lancer Python 2.7, tapez python2.7, ou pour lancer Python 3.6, tapez python3.6.

En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez pythonX.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon, mais comme on a souvent plusieurs versions de Python installées sur une machine (sans parfois même sans rendre compte), c’est important de le faire.

Pour les linuxiens seulement

Pip et virtualenv sont fournis quand on installe Python sous Mac et Windows, mais souvent pas sous Linux ! Assurez-vous de toujours les installer avec votre gestionnaire de paquet, et ce pour chaque version de Python que vous avez.

Exemple: yum install python3.6-pip ou apt install python3.6-venv.

Tous OS confondus

Quand vous utilisez une commande écrite en Python, mettez python -m devant. C’est un cheat code.

N’appelez-pas pip, mais python -m pip.

N’appelez-pas venv, mais python -m venv.

N’appelez-pas black, mais python -m black.

Si vous lisez dans un tutoriel “tapez pip install”, remplacez-le mentalement par “tapez python -m pip install”.

-m ne marche pas avec toutes les commandes (python -m jupyter console a un bug, snif) car cela suppose que le développeur de la commande y a pensé, mais c’est le cas de la plupart des outils modernes.

Or -m va vous éviter tout un tas de problème de PATH, de droits et de version de Python.

Donc, si on combine tous les conseils, n’utilisez pas pip, mais py -3.6 -m pip ou python3.6 -m pip.

Je sais, c’est plus long a taper, mais ça va bien vous aider.

pip install

Certains outils doivent s’installer en global. On voit souvent des conseils comme faire un sudo pip install ou un sudo easy_install. C’est mal. Ceci va pourrir les paquets système de Python, et peut avoir des conséquences indésirables. Notez que parfois, rien ne marche, et je le fais quand même du coup.

Mais la plupart du temps, ce qu’il vous faut, c’est --user, suivi de -m. Par exemple, ne faites pas:

 
sudo pip install black 
black mon_fichier.py 

Mais faites:

 
python3.6 -m pip install black --user 
python3.6 -m black mon_fichier.py 

Notez le --user, ainsi que les deux usages de -m.

Ceci va installer black localement, pas au niveau du système. On s’assure qu’on n’utilise bien Python3.6, à l’installation et à l’usage de black. Et comme on n’utilise -m, on a pas à se demander si la commande black est bien sur le PATH (pas besoin de trifouiller son .bashrc ou le sys PATH de Windows.)

Mais c’est trop chiant !

Absolulement, c’est aussi pour cela qu’on utilise des environnements virtuels.

Utilisez des virtualenvs. Abusez-en. Un virtualenv par projet. Un autre pour les tests rapidos. Un pour maman, un pour papa, et un pour le fun. Ils ne coûtent rien que quelques Mo sur votre disque dur, donc lâchez-vous.

Car dans un virtualenv, non seulement vous êtes isolés des autres installations de Python, mais en plus… tous les conseils ci-dessus ne sont plus nécessaires !

Vous pouvez taper juste python et juste pip, plus de py, plus de suffixes, plus de -m et --user. Joie !

Moralité: les rares fois où vous êtes hors virtualenv, suivez les conseils des autres parties de l’article (py -3.6 -m pip install --user ou python3.6 -m pip install --user). Et des que vous le pouvez, pouf, virtualenv, et tout va pour le mieux.

Entre alors pipenv, que j’ai testé il y a presque un an, et qui au départ montrait un beau potentiel, mais n’était pas encore très utilisable. J’ai fait quelques suggestions d’amélioration, comme permettre de choisir précisément la version de Python, et je me suis fait envoyé bouler. J’ai donc laissé l’auteur s’enterrer dans sa recherche de gloire passée.

Le hasard de reddit m’a remis pipenv sous le nez, et j’ai donc redonné sa chance au produit. Surprise, l’outil est maintenant très stable (plus de 2000 commits !) et mes propositions avaient même été intégrées.

Après ces 3 paragraphes vous vous demandez sans doute quand est-ce que je vais rentrer dans le vif du sujet, donc:

pipenv reprend les idées de pip, virtualenv, pew et même quelques trucs de npm, yarn, cargo, et essaye d’appliquer tout ça à Python. L’article suppose que vous savez ce que sont ces mots barbares, donc suivez les liens si ce n’est pas le cas.

pipenv permet donc d’installer des packages Python, d’isoler cette installation et de la rendre reproductible. Mais sans effort.

En effet, contrairement à la concurrence:

• La gestion du virtualenv est automatique et transparente
• Les paquets installés sont sauvegardés dans des fichiers de config, encore une fois de manière automatique et transparente.
• Les fichiers de config distinguent les dépendances de prod et de dev, et incluent les versions des sous-dépendances.

Installer pipenv

Contrairement à pip et virtualenv, pipenv n’est pas fourni avec une installation standard de Python, bien que l’outil soit maintenant recommandé par la doc officielle. Il va donc falloir l’installer. Or pipenv se base sur une version récente de pip, donc il faut d’abord être sûr d’avoir pip à jour.

Du coup:

# mise à jour de pip, mais juste au niveau utilisateur pour 
# pas casser le  system
python -m pip install pip --upgrade --user

Puis:

# installation de pipenv
python -m pip install pipenv --user

A moins d’être sous une Debian like type Ubuntu (qui demande un apt install de python-pip avant), tout le monde a pip installé avec une version moderne de Python.

Voilà, vous devriez avoir la commande pipenv disponible, ou pour ceux qui ont un système mal configuré, python -m pipenv.

Usage

Dans le dossier de votre projet:

pipenv install nom_du_package

C’est tout.

Si un virtualenv n’existe pas il sera créé. Sinon il sera utilisé. Les fichiers de configs sont gérés automatiquement, il n’y a rien à faire.

Si vous voulez lancer une commande dans le virtualenv:

pipenv run commande

Exemple:

pipenv run python

Va lancer le Python de votre virtualenv.

Si vous voulez que toutes les commandes soient dans le virtualenv:

pipenv shell

Et vous êtes dans un nouveau shell, dans le virtualenv. Ainsi:

python

Lancera celui de votre virtualenv.

On sort du shell avec Ctrl + D.

Vous pouvez arrêtez de lire l’article ici, c’est l’essentiel de ce qu’il y a à savoir.

Astuces

Si vous lancez pour la première fois dans un dossier pipenv avec:

pipenv --python x.x

Le virtualenv sera créé avec la version de Python x.x, pourvu qu’elle existe sur votre système. Setter la variable d’env PIPENV_DEFAULT_PYTHON_VERSION a le même effet.

Installer un package avec pipenv install --dev le marque comme dépendance de développement uniquement, et permet une installation séparée.

Vous pouvez aussi obtenir quelques infos utiles comme:

• pipenv --venv: ou est le dossier du virtualenv
• pipenv graph: un graph de toutes vos dépendances
• pipenv --py: chemin vers le Python en cours.

Enfin pipenv utilise pew, donc la magie de pew reste dispo, y compris la gestion de projets :)

Usage avancé

Si vous créez un fichier .env dans le dossier de votre projet tels que:

FOO=1
BAR=wololo

pipenv exécutera toutes ses commandes (y compris shell), avec FOO et BAR comme variables d’environnement.

La commande:

pipenv lock

Va créer un lock file. Ce fichier contient toutes les dépendances, et recursivement, les dépendances des dépendances, installées, avec leurs versions. On peut réutiliser ce fichier en prod pour installer une exacte copie de son setup local avec pipenv install. Sans ce fichier, pipenv install se comportera comme pip install.

Il y a plein d’autres trucs mais on va en rester là.

Inutilisable.

Aujourd’hui plutôt que de subir le problème, j’ai cherché une solution, et pouf : quand on utilise des couleurs dans son prompt, il faut entourer tout le balisage de [].

Mais le balisage qui colore le prompt est composé de séquences d’échappements, qui contiennent aussi [], donc il faut mettre des anti-slash.

Du coup on passe de ça :

export PS1="\[\033[01;34m\]\$(basename '$VIRTUAL_ENV')\e[0m $PS1"

à :

export PS1="\[\033[01;34m\]\$(basename '$VIRTUAL_ENV')[\e[0m] $PS1"


à la solution qui marche :

export PS1="\[\033[01;34m\]\$(basename '$VIRTUAL_ENV')\[\e[0m\] $PS1"

Évidemment à appliquer à tous les codes d’échappement chelou qu’on a réparti un peu partout.

J’ai un tampon prêt à tirer pour le premier qui me parle de zsh.

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
]]>
			http://sametmax.com/a-linterieur-de-mon-bashrc/feed/
		24
	4238	
		
		
		http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/
		http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/#comments
		Fri, 19 Oct 2012 16:49:18 +0000
		
				
		
		

		http://sametmax.com/?p=2660
		
				Quand on commence à beaucoup programmer, on accumule rapidement plusieurs projets en cours de développement sur sa machine. Certains vieux, certains récents, qui utilisent tous des bibliothèques similaires, mais pas forcément de mêmes versions. Ou parfois des bibliothèques incompatibles. Parfois même, des version différentes de Python: Python 2.6, 2.7, 3.2 ? Et c’est sans compter les mises à jour de l’OS, qui a ses propres besoins en terme de libs et de versions.

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, qui peut être installé séparément sur les versions plus anciennes sous le nom de virtualenv.
Installation et usage
Vérifiez si vous avez virtualenv déjà installé:
$ python -m venv
usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear]
            [--upgrade] [--without-pip]
            ENV_DIR [ENV_DIR ...]
venv: error: the following arguments are required: ENV_DIR

Si cette commande ne marche pas, il faudra 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, avec:
python -m venv /path/vers/projet/env_nom_du_projet
Si vous l’aviez déjà. Ou:
virtualenv /path/vers/projet/env_nom_du_projet
Si vous venez de l’installer. Les deux commandes sont interchangeables.
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.
]]>
			http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/feed/
		48
	2660	
		
		
		http://sametmax.com/arf-on-avait-laisse-lancien-formulaire-de-contact/
		Thu, 11 Oct 2012 15:53:48 +0000
		
				
		
		
		
		

		http://sametmax.com/?p=2553
		
				Le lien vers l’ancien formulaire de contact était toujours accessible, et du coup on a reçu un mail depuis celui-ci, alors qu’on ne peut pas y répondre.

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 !
@+
]]>
		2553	
		
		
		http://sametmax.com/un-peu-de-ruby-dans-du-python/
		http://sametmax.com/un-peu-de-ruby-dans-du-python/#comments
		Wed, 26 Sep 2012 13:58:13 +0000
		
				
		
		
		

		http://sametmax.com/?p=2297
		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.]]>
				Si vous utilisez un virtualenv, vous n’avez pas envie d’installer des libs au niveau du système. 

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.
]]>
			http://sametmax.com/un-peu-de-ruby-dans-du-python/feed/
		4
	2297