noirbizarre

Cette utilisateur n'a partagé aucune information biographique

Accueil: http://noirbizarre.info


Article par noirbizarre

Définir l’exécution par défaut d’un plugin maven

3/10/11

Posté par noirbizarre dans Java

Aucun commentaire

Avec Maven, il arrive souvent d’avoir à définir plusieurs exécutions d’un plugin pour différentes phases mais de vouloir en garder une par défaut (celle utilisée en ligne de commande).

Depuis la version 2.2 de maven, le ticket MNG-3401 le permet en donnant l’identifiant d’exécution default-cli:

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <executions>
    <execution>
      <id>default-cli</id>
      <configuration>
        <descriptorRefs>
          <descriptorRef>jar-with-dependencies</descriptorRef>
          <descriptorRef>project</descriptorRef>
        </descriptorRefs>
      </configuration>
    </execution>
  </executions>
</plugin>

Eviter d’utiliser stage.addEventListener()

3/08/11

Posté par noirbizarre dans Flex

Aucun commentaire

En Flex/ActionScript, il n’est pas rare de vouloir écouter un évènement au niveau le plus haut et de voir du code tel que:

if (stage) {
	stage.addEventListener(MonEvent.MON_TYPE, _monHandler);
} else {
	this.addEventListener(Event.ADDED_TO_STAGE, function(e:Event):void{
		stage.addEventListener(MonEvent.MON_TYPE, _monHandler);
	});
}

En effet, lors de l’inialisation des composants Flex, l’attribut stage n’est pas encore disponible.

Pourtant, il est plus simple et plus propre d’utiliser SystemManager:

systemManager.addEventListener(MonEvent.MON_TYPE, _monHandler);

Ce morceau de code ne plantera pas car systemManager est initilisé dès le lancement de l’application et est toujours présent dans les composants, contrairement à stage.

, , ,

Java et proxy HTTP

6/04/11

Posté par noirbizarre dans Java

Aucun commentaire

Comment faire en sorte qu’une application Java passe par un proxy HTTP (comme c’est souvent le cas en entreprise) ?
Il faut le spécifier dans les options de la JVM à l’execution!
On me pose souvent la question et même si je connais la réponse, je doit toujours la rechercher pour être sur de la syntaxe.
Les options à passer sont:

  • http.proxyHost pour spécifier l’hôte
  • http.proxyPort pour spécifier le port
  • http.proxyUser pour spécifier le nom d’utilisateur (optionnel)
  • http.proxyPassword pour spécifier le mot de passe (optionnel)

Ce qui donnerai en ligne de commande pour un proxy dont l’url est http://user:password@proxy.maboite.com:8080

~$ java -Dhttp.proxyHost=proxy.maboite.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=user -Dhttp.proxyPassword=password maClasse
, ,

Jetty 7 et Hudson sous Debian Lenny

7/01/11

Posté par noirbizarre dans Admin

2 commentaires

Dans cet article décrit l’installation en tant que service de Jetty 7 sur Debian Lenny ainsi que le déploiement de Hudson.

Installation d’OpenJDK 6 Headless

Avant toute chose, il faut une installation de JRE fonctionnelle, dans mon cas OpenJDK 6 Headless.

noirbizarre:~$ sudo aptitude install openjdk-6-jre-headless

Installation de jetty

Nous allons créer un utilisateur jetty et le groupe associé et les utiliser pour installer et exécuter jetty.

noirbizarre:~$ sudo groupadd jetty
noirbizarre:~$ sudo useradd -s /bin/bash -d /home/jetty -m -g jetty jetty
noirbizarre:~$ sudo passwd jetty

Après voir récupéré la dernière version stable de Jetty 7 disponible ici, dans mon cas la version 7.2.2.v20101205., et on l’installe dans le $HOME de notre utilisateur.

noirbizarre:~$ sudo -i -u jetty
jetty:~$ JETTY_VERSION=7.2.2.v20101205
jetty:~$ wget http://download.eclipse.org/jetty/$JETTY_VERSION/dist/jetty-distribution-$JETTY_VERSION.tar.gz
jetty:~$ tar -xvzf jetty-distribution-$JETTY_VERSION.tar.gz
jetty:~$ ln -s jetty-distribution-$JETTY_VERSION jetty7

Nous allons lancer jetty une première fois pour vérifier que tout s’execute bien:

jetty:~$ cd jetty7
jetty:~/jetty7$ java -jar start.jar
2011-01-07 00:58:19.337:INFO::jetty-7.2.2.v20101205
2011-01-07 00:58:19.410:INFO::Deployment monitor /home/jetty/jetty-distribution-7.2.2.v20101205/webapps at interval 1
2011-01-07 00:58:19.426:INFO::Deployment monitor /home/jetty/jetty-distribution-7.2.2.v20101205/contexts at interval 1
2011-01-07 00:58:19.432:INFO::Deployable added: /home/jetty/jetty-distribution-7.2.2.v20101205/contexts/test.xml
2011-01-07 00:58:19.568:INFO::Extract jar:file:/home/jetty/jetty-distribution-7.2.2.v20101205/webapps/test.war!/ to /tmp/jetty-0.0.0.0-8080-test.war-_-any-/webapp
2011-01-07 00:58:21.438:INFO:org.eclipse.jetty.servlets.TransparentProxy:TransparentProxy @ /javadoc to http://download.eclipse.org/jetty/stable-7/apidocs
2011-01-07 00:58:21.441:INFO::Deployable added: /home/jetty/jetty-distribution-7.2.2.v20101205/contexts/javadoc.xml
2011-01-07 00:58:21.523:INFO::Started SelectChannelConnector@0.0.0.0:8080

Une fois l’initialisation terminée, on peut se connecter sur http://localhost:8080 pour afficher la page d’accueil de Jetty ainsi que quelques exemples.

On peut maintenant couper le serveur et quitter la session de l’utilisateur jetty.

Déploiement de jetty en tant que service

Pour démarrer Jetty en tant que service on utilise le script fourni dans le repertoire bin.

noirbizarre:~$ sudo cp /home/jetty/jetty7/bin/jetty.sh /etc/init.d/jetty
noirbizarre:~$ sudo chmod u+x /etc/init.d/jetty

Toutes les variables d’environnement sont à déclarer dans /etc/default/jetty.

JETTY_USER=jetty
JETTY_HOME=/home/$JETTY_USER/jetty7

noirbizarre:~$ sudo /etc/init.d/jetty check
Checking arguments to Jetty:
JETTY_HOME     =  /home/jetty/jetty7
JETTY_CONF     =  /home/jetty/jetty7/etc/jetty.conf
JETTY_RUN      =  /var/run
JETTY_PID      =  /var/run/jetty.pid
JETTY_PORT     =
JETTY_LOGS     =
START_INI      =  /home/jetty/jetty7/start.ini
CONFIGS        =  --pre=etc/jetty-logging.xml
JAVA_OPTIONS   =  -Djetty.home=/home/jetty/jetty7 -Djava.io.tmpdir=/tmp
JAVA           =  /usr/bin/java
CLASSPATH      =
RUN_CMD        =  /usr/bin/java -Djetty.home=/home/jetty/jetty7 -Djava.io.tmpdir=/tmp -jar /home/jetty/jetty7/start.jar --pre=etc/jetty-logging.xml
noirbizarre:~$ sudo /etc/init.d/jetty
Usage: jetty [-d] {start|stop|run|restart|check|supervise} [ CONFIGS ... ]
noirbizarre:~$ sudo /etc/init.d/jetty start
Starting Jetty: OK
noirbizarre:~$ sudo /etc/init.d/jetty stop
Stopping Jetty: OK

Une fois toutes les vérifications effectuées, pour lancer Jetty au démarrage du serveur:

noirbizarre:~$ sudo update-rc.d jetty defaults

Installation de Hudson

On installe Hudson avec l’utilisateur jetty en lui specifiant de travailler dans le répertoire /home/jetty/hudson:

noirbizarre:~$ echo 'export HUDSON_HOME=/home/$JETTY_USER/hudson' | sudo tee -a /etc/default/jetty
noirbizarre:~$ sudo -i -u jetty
jetty:~$ cd jetty7/webapps
jetty:~/jetty7/webapps$ wget http://mirrors.hudson-labs.org/war/latest/hudson.war

Il n’y a plus qu’a démarrer jetty et vérifier que http://localhost:8080/hudson affiche bien l’accueil de Hudson.

, , , ,

pip, virtualenv et virtualwrapper dans Cygwin

10/12/10

Posté par noirbizarre dans Développement

Aucun commentaire

Voici la marche à suivre pour installer Python, pip, virtualenv et virtualenvwrapper dans Cygwin (version 1.7.7-1 à ce jour).

Python doit être installé via l’installeur de Cygwin.

Pour installer pip, nous allons utiliser easy_install qui est fourni par setuptools (version 0.6c11 au moment où j’écris ces lignes). Pour trouver la dernière version en date correspondant à notre version de Python (version 2.6.5 fournie par Cygwin), il faut se rendre sur la page officielle.

~$ wget http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
~$ sh setuptools-0.6c11-py2.6.egg
~$ easy_install pip

Une fois pip installé, il suffit de l’utiliser pour installer virtualenv et virtualenvwrapper

~$ pip install virtualenv virtualenvwrapper

On configure notre environnement dans .bashrc:

# Python pip / virtualenv / virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true
source /usr/bin/virtualenvwrapper.sh

Ensuite, tout fonctionne comme dans cet article.

, , ,

Git: l’essentiel

6/12/10

Posté par noirbizarre dans Développement

Aucun commentaire

Git est un scm qu’on ne présente plus. Bien que très pratique il peut se révéler très compliqué à utiliser.

Les commandes de base

Voici les commandes que j’utilise le plus:

  • git commit : publie localement les changements.
  • git checkout myBranch : change la branche courante pour myBranch.
  • git checkout -b myNewBranch : crée la branche myNewBranch et la définie comme branche active.
  • git branch : liste les branches locales.
  • git branch -a : liste toutes les branches.
  • git status : liste tous les changements non publiés.
  • git stash :  met de côté tous les changements effectués depuis le dernier commit.
  • git stash apply : restaure les changement mis de côté avec git stash.
  • git log -n : liste les n derniers commits.

Le fichier ~/.gitconfig

git gère 3 niveaux de configuration:

  1. Le niveau système dans /etc/gitconfig qui s’applique à tous les utilisateurs
  2. Le niveau global dans ~/.gitconfig qui s’applique à l’utilisateur courant
  3. Le niveau dépôt dans $GIT_REPO/.git/config qui s’applique uniquement au repository courant

Celui qui nous intéresse en l’occurrence est le niveau global.

Pour commencer, il va contenir la section user permettant de nous identifier:

[user]
name = Axel H.
email = noirbizarre@gmail.com

Pour certains projet, il pourra être intéressant de modifier ces informations d’identification.

Ces informations pourront être spécifiées directement depuis le shell:

~$ git config --global user.name "Axel H."
~$ git config --global user.email noirbizarre@gmail.com

D’autres options pourront être ajoutées, telle que la coloration:

[color]
diff = auto
status = auto
branch = auto
interactive = auto
ui = true
pager = true

ou encore des alias:

[alias]
co = checkout
ci = commit
st = status
br = branch

Avec ces alias on pourra tapper:

~$ git co mabranch
~$ git ci -m "Mon commentaire"
~$ git st

Il est possible de trouver énormément d’options à rajouter dans ~/.gitconfig sur la web, notemment sur StackOverflow, et particulièrement ce thread.

Comme d’habitude, pas de secrets, tout est dans le man.

Le fichier .gitignore

Le fichier .gitignore permet de spécifier une liste de fichiers qui ne seront jamais pris en compte par git.

Je ne referais pas la documentation officielle, mais ce qu’il faut retenir c’est:

  • Les lignes commençant par # sont des commentaires
  • le ! permet de prendre la négation d’un pattern
  • le / en début de pattern spécifie la racine par rapport au fichier .gitignore
  • le / en fin de pattern spécifie un répertoire et tous ses sous répertoires
  • tous les shell glob patterns sont pris en charge

Pour une documentation complète sur gitignore, la page man reste la référence.

Il est possible de spécifier un .gitignore global, par exemple:

~$ echo "*~" >> ~/.gitignore
~$ echo "*.swp" >> ~/.gitignore
~$ echo "*.pyc" >> ~/.gitignore
~$ git config --global core.excludesfile ~/.gitignore

Cela permet d’éviter de ressaisir les fichiers qui sont toujours à exclure de git (fichiers temporaires, produits de compilation, ….).

Liste des règles

Dokuwiki et Cherokee

4/12/10

Posté par noirbizarre dans Admin

Aucun commentaire

Pour faire tourner une installation secure de dokuwiki dans Cherokee avec les spécifications suivantes:

  • Accessible depuis https://wiki.noirbizarre.info/
    • uniquement https
    • à la racine du domaine
    • certificat autosigné
  • Récriture des URLs propres
  • DocumentRoot situé dans /var/www/noirbizarre.info/wiki
  • Logs situés dans /var/logs/cherokee/noirbizarre.info (wiki.access et wiki.errors)

Ce tutoriel a été rédigé pour une version 1.0.8 de Cherokee tournant sous Debian Lenny. Les libellés et les screenshots peuvent varier d’une version à l’autre.

Installation du wiki

Pour commencer on récupère la dernière version de dokuwiki ici et on crée l’arborescence nécéssaire.

~$ wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2010-11-07.tgz
~$ sudo mkdir -p /var/www/noirbizarre.info
~$ tar xvzf dokuwiki-2010-11-07.tgz
~$ sudo mv dokuwiki-2010-11-07 /var/www/noirbizarre.info/wiki
~$ sudo chown -R www-data:www-data /var/www/noirbizarre.info/wiki
~$ sudo mkdir -p /var/log/cherokee/noirbizarre.info
~$ sudo chown -R www-data:www-data /var/log/cherokee/noirbizarre.info

Génération du certificat

Pour cet exemple, nous allons utilisé un certificat autosigné. Il permet de crypter la communication mais le fait qu’il soit auto signé ne permet d’authentifier l’hôte distant. OpenSSL doit être installé pour cette étape. En répondant aux questions, on s’assurera que Common Name est bien rempli avec le nom de domaine (Cherokee s’en sert pour le routage).

~$ openssl req -new -x509 -nodes -out wiki.crt -keyout wiki.key -days 3650
Generating a 1024 bit RSA private key
...............................................++++++
.++++++
writing new private key to 'wiki.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:noirbizarre.info
Organizational Unit Name (eg, section) []:WiKi
Common Name (eg, YOUR name) []:wiki.noirbizarre.info
Email Address []:
~$ mv wiki.crt wiki.key /var/www/noirbizarre.info

Création du vServer

Pour cette étape, nous considérons que Cherokee est installé, fonctionnel, configuré pour géré le SSL sur le port 443 et tourne avec les droits de www-data:www-data.

On se connecte sur l’interface d’administration via localhost:9090.

On crée un nouveau vServer nommé wiki.noirbizarre.info et ayant pour DocumentRoot /var/www/noirbizarre.info/wiki.

Ajout d'un vServer

Ajout d'un vServer pour le wiki

Le nom du vServer est important, il permet à Cherokee de router les requetes vers le bon vServer.

Gestion des logs

Dans l’onglet journalisation du vServer créé, spécifier:

  • Dans Error Logging:
    • Write errors to: fichier
    • Nom de fichier: /var/log/cherokee/noirbizarre.info/wiki.errors
  • Dans Access Logging:
    • Nom de fichier: /var/log/cherokee/noirbizarre.info/wiki.access
Journalisation

Gestion des logs

Gestion du SSL

Sur l’onglet sécurité on spécifie les chemins des fichiers .crt et .key générés.

Sécurité

Gestion des certificats

Règles de gestion

Sur l’onglet Behavior, on clique sur Rule Management pour ouvrir le gestionnaire de règle et on supprimer les 2 règles Contenu statique créées par défaut de façon à ne garder que la règle Par défaut.

Nous allons maintenant modifier la règle Par défaut pour lui faire prendre en charge les redirections et ajouter 3 règles supplémentaires:

  • Gestion du contenu statique
  • Gestion du php
  • Redirection vers https
Règle Par défaut

Sur l’onglet Gestionnaire, on choisit Redirection dans la liste déroulante et on rentre les règles internes suivantes:

  • ^/_media/([^/]+)\?(.+)$ → /lib/exe/fetch.php?media=$1&$2
  • ^/_media/([^/]+)$ → /lib/exe/fetch.php?media=$1
  • ^/_detail/([^/]+)\?(.+)$ → /lib/exe/detail.php?media=$1&$2
  • ^/_detail/([^/]+)$ → /lib/exe/detail.php?media=$1
  • ^/_export/([^/]+)/(.*)$ → /doku.php?do=export_$1&id=$2
  • ^/$ → /doku.php
  • ^/\?([^/]+)$ → /doku.php?$1
  • ^/([^/]+)\?(.*)$ → /doku.php?id=$1&$2
  • ^/([^/]+)$ → /doku.php?id=$1
Règles de redirection

Règles de redirection

L’ordre est important puisque Cherokee s’arrêtera à la première règle qui match.

On pourra aussi autoriser la compression gzip et deflate depuis l’onglet Encodage pour optimiser les transferts, et ce pour chaque règle que l’on rajoute.

Encodage

Encodage

Contenu statique

On va spécifier à Cherokee  que le fichier favicon.ico et le repertoire /lib sont du contenu statique et qu’il doit le traiter comme tel.

On rajoute alors la règle et le handler correspondant.

Règle de contenu statique

Règle de contenu statique

Gestionnaire de contenu statique

Gestionnaire de contenu statique

Il n’est pas nécéssaire de respécifier le DocumentRoot puisque celui du vServer est repris par défaut.

Prise en charge du php

Pour cette étape, on considère que php5 et php5-cgi sont installés.

On rajoute maintenant une règle extension pour capter tous les appels de fichiers php.

Pour cela, Cherokee fourni un assitant qui créée automatiquement la règle. On pourra personnaliser les valeurs, comme par exemple l’encodage, ou encore la prise en charge de fcgi.

Assistant php

Assistant php

Il faut ensuite passer la règle en status FINAL en cliquant sur NON FINAL dans la liste des règles à gauche.

Liste des règles

Liste des règles et leur statut

Redirection vers HTTPS

Cette dernière règle va automatiquement rediriger l’utilisateur sur la version sécurisée du site.

Pour cela on rajoute une règle SSL/TLS dont on va prendre la négation et on y affecte un handler de redirection externe (visible par l’utilisateur).

Règle "n'est pas SSL"

Règle "n'est pas SSL"

Redirection vers la version sécurisée

Redirection vers la version sécurisée

Premier accès

Nous pouvons maintenant enregistrer nos changements et rédémarrer Cherokee.

Redémarrage de Cherokee

Redémarrage de Cherokee

Nous pouvons maintenant accéder à https://wiki.noirbizarre.info/install.php et suivre la procédure d’installation. Il faut pour cela que votre serveur DNS redirige bien wiki.noirbizarre.info vers votre serveur.

Un message d’avertissement nous signalera que notre certificat n’est pas sur puisqu’il est autosigné.

Installation de dokuwiki

Installation de dokuwiki

Une fois l’installation effectuée, authentifiez vous et dans les paramètres de configurations spécifier les URLs esthétiques sur .htaccess.

URLs esthétiques

URLs esthétiques

Et voilà, vous pouvez maintenant tester la redirection HTTPS et les URLs esthétiques. Tout fonctionne correctement.

, ,
Configuration de l'executable python

pip, virtualenv, virtualenvwrapper et pydev

10/07/10

Posté par noirbizarre dans Développement

Aucun commentaire

L’une des difficultés majeures du développement aujourd’hui est la gestion des dépendances et en particulier pour Python l’isolement de l’environnement de développement.

Pour résoudre ce problème, nous allons utiliser :

  • pip: un remplaçant d’easy_install bien plus complet.
  • virtualenv: permet d’instancier des environnements python isolés.
  • virtualenvwrapper: facilite l’utilisation de virtualenv

Installation des outils de développement

Si ce n’est déjà fait, il faut installer un environnement de développement python classique:

~$ sudo aptitude install python-setuptools python-dev build-essential

Nous installons la dernière version de pip:

~$ sudo easy_install pip

Puis nous installons virtualenv et virtualenvwrapper

~$ sudo pip install virtualenv virtualenvwrapper

Il faut maintenant configurer notre environnement en ajoutant au fichier ~/.bahrc

# Python pip / virtualenv / virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true
source /usr/local/bin/virtualenvwrapper.sh

Puis nous initialisons l’environnement:

~$ mkdir ~/.virtualenvs
~$ source ~/.bashrc
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/initialize
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/premkvirtualenv
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/postmkvirtualenv
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/prermvirtualenv
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/postrmvirtualenv
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/predeactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/postdeactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/preactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/postactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/get_env_details

Nous sommes maintenant prêts à instancier notre premier environnement.

Création d’un environnement isolé

Il suffit maintenant d’utiliser la commande mkvirtualenv.

~$ mkvirtualenv --no-site-packages myenv
New python executable in myenv/bin/python
Installing setuptools............done.
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/myenv/bin/predeactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/myenv/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/myenv/bin/preactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/myenv/bin/postactivate
virtualenvwrapper.user_scripts Creating /home/noirbizarre/.virtualenvs/myenv/bin/get_env_details
(myenv)~$

L’option –no-site-packages permet d’avoir une installation de python nue, c’est à dire sans aucune des dépendances python ajoutées dans l’installation courante.

Utilisation en ligne de commande

Une fois l’environnement actif, le prompt du shell est préfixé par « (nom de l’environnement) ».

Pour désactiver l’environnement, il suffit d’executer:

(myenv)~$ deactivate
~$

Pour réactiver l’environnement il suffit d’executer

~$ workon myenv
(myenv)~$

La liste complète des commandes de virtualenvwrapper est disponible ici.

Utilisation dans Eclipse/Pydev

Pour utiliser cet environnement dans eclipse avec Pydev il suffit d’aller dans Preferences > Pydev > Interpreter Python et d’ajouter l’executable python qui correspond, dans notre cas ~/.virtualenvs/myenv/bin/python.

Configuration de l'executable python

Sur l’écran qui apparait ensuite, il ne faut selectionner que les chemin qui correspondent à notre environnement (ceux commençant par ~/.virtualenvs/myenv/).

Sélection des chemins

L’environnement apparait ensuite dans la liste des environnement disponibles.

Préférences Pydev de l'interpreteur python

Il suffit ensuite de le sélectionner dans les préférences des projets concernés.

Sélection de l'interpréteur python d'un projet

Utilisation de pip

Lorsque l’environnement est actif, pip s’utilise comme apt/aptitude.

# Recherche de paquets
(myenv)~$ pip search mypackage

# Installation d'un paquet
(myenv)~$ pip install mypackage

Lorsque l’environnement est inactif, il est possible de specifier à pip un environnement pour l’installation avec l’option -E:

~$ pip install -E myenv mypackage

Il est possible de dumper tous les modules installé dans un fichier:

~$ pip freeze > requirements

Puis de les recharger d’un coup dans un autre environnement:

~$ pip install -r requirements

Pour plus de détails sur l’utilisation de pip, la page officielle fait office de documentation.

, , , ,