Bonjour,
je me pose une question sur l’installation des packges python.
J’en ai certains d’installés par apt-get, ils sont dans /usr/lib/python2.7/dist-packages
et j’en ai d’autres installés par pip dans /usr/local/lib/python2.7/dist-packages
Je me pose 2 questions:
[ul]quelle solution faut il privilégier ?
Que ce passe t il si un package est installé simultanément par les 2 méthodes ? Lequel est utilisé (il y a peu de chance qu’ils soient à la même version) ?
[/ul]
pip est bien entendu souvent plus récent (au pire à la même version) même pour une SID, pour ma part je n’utilise que “apt-get” sur une SID pour éviter des déboires au moment des mise à jour; je pense que apt-get serait acapable de mettre à jour un module python avec une version plus ancienne … Et puis c’est plus facile pour la portabilité de l’appli !
Le probléme, c’est qu’il n’y a pas tout avec apt-get.
de plus certains installeurs installent les packages requis via pip ou easy-install.
Ca devient vite compliquer à gérer.
Ce qu’il n’y a pas avec apt-get ne va pas rentrer en conflit 
pas forcement, à cause des dépendances.
Tu installes avec pip, et il t’installe un autre package dépendant, . Je ne sais pas si il peut voir que la dépendance est déja installée par apt-get
Et aptitude ?
Au niveau dépendance, il est plus “pointu” que apt-get.
Salut,
Puisque tous le monde (vu 80 fois) semble connaître cette installateur, de quoi en retourne t-il ?
C’est globalement le même principe que CPAN pour Perl, ASDF pour Lisp, NPM pour Node.js, etc. En gros, il contourne complètement le système de paquets Debian, il va chercher ce dont il a besoin dans des dépôts tiers. Comme ces dépôts tiers ne fournissent pas des .deb mais des “trucs” dans un format totalement différent, ça ne s’intègre pas correctement avec dpkg/apt-get et il peut y avoir des doublons voire des conflits de version.
La question étant : comment résoudre ces conflits ? (moi j’en sais rien)
Il y a aussi un peu la même problématique avec Ruby ( linuxfr.org/news/l-admin-presse-rvm )
Si certain(e)s n’avaient pas compris ce qu’est [mono]pip[/mono], il s’agit non pas d’un gestionnaire de paquets .deb, mais un installateur de briques python (pas de page Fr: en.wikipedia.org/wiki/Pip_%28package_manager%29 ). Mais puisque APT permet également d’installer des librairies python, il y a conflit.
Re,
C’est globalement le même principe que CPAN pour Perl, ASDF pour Lisp, NPM pour Node.js, etc. En gros, il contourne complètement le système de paquets Debian, il va chercher ce dont il a besoin dans des dépôts tiers. Comme ces dépôts tiers ne fournissent pas des .deb mais des “trucs” dans un format totalement différent, ça ne s’intègre pas correctement avec dpkg/apt-get et il peut y avoir des doublons voire des conflits de version.
La question étant : comment résoudre ces conflits ? (moi j’en sais rien)[/quote]
Et bien pour le coup, je m’endormirai un peu moins ignare ce jour.
CPAN, perl -MCPAN & perl Makefile.PL, python load le-script.py que j’utilise de temps à autre, pour le reste n’étant pas un dev …
À présent [mono]$ pip install ./downloads/SomePackage-1.0.4.tar.gz[/mono] je suis en mesure de comprendre les difficultés qui peuvent en découler.
Merci à vous deux. 
pip (anciennement easy-install) permet de gérer des environnement virtuels python, chose que ne sait pas faire apt.
C’est à dire que tu peux avoir plusieurs versions d’un même package installé, pour des projets différents, mais chacun dans un environnement virtuel différent.
La solution à mon problème est peut étre là.
Sans étre dev, tu peux étre amené à utiliser pip si tu utilises un projet en python qui n’est pas encore complétement packagé (domogik dans mon cas). Il te faut parfois installer un package toi même.