pip3 install pandas
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

J'ai quand même du mal avec l'environnement python que je trouve super... bordelique.
Y'a plein de possibilité mais des emmerdes possibilité²
Très chiant je trouve.

Je suis en train d'installer python et mon environnement sur mon serveur de prod, et après avoir mis à jour pip, bim, je me mange ça. Je vais trouver une solution en googlant le problème.. mais vraiment, j'ai une mauvaise impression sur l'environnement python et sa stabilité.

Ces problèmes viennent typiquement quand tu as Python/pip installé au niveau du système, et qu'ils sont utilisés en dehors d'environnements isolés. En l'occurrence, je pense que ta commande "pip3" (dans /usr/bin/pip3) est fournie par le système, alors que le "pip" utilisé en "arrière-plan" a été mis à jour "localement" (soit dans l'environnement où tu es, soit - plus probablement - via une upgrade directe via pip ; dans tous les cas, pas via le système, d'où la "désynchronisation" entre le script "pip3" dans usr/bin et sa réelle implémentation au sein de Python).

C'est pour ça que je suggère toujours d'utiliser des environnements virtuels (et de se laisser tenter par "pew" qui permet de gérer ça très simplement), ainsi tu sais exactement que ce que tu utilises dans ton environnement ne dépend que de ton environnement. Ca évite aussi les mélanges entre pip2/pip3 et python2/python3 (typiquement installés sur un Linux par défaut) puisque ton environnement définit *une* version de Python à utiliser, et tous les outils classiques ("python", "pip", ...) pointent vers cette version.

En l'état, je pense que tu vas devoir désinstaller pip3 via ton package manager (système), puis le réinstaller.

J'avais testé pew vite fait sans être fan.
Là du coup j'ai désinstallé tout python, tout pip, et installé uniquement python3 et pip3
Du coup cela refonctionne.
Mais oui clairement, les environnements multiples, ça fou la merdouille

yaugJ'avais testé pew vite fait sans être fan.

Peux-tu développer ? Je peux peut-être t'orienter vers d'autres solutions du coup ?

yaugMais oui clairement, les environnements multiples, ça fou la merdouille

En effet Mais c'est la même chose pour la plupart des langages, sauf que c'est un peu moins visible car la plupart des langages proposent une compatibilité ascendante, ce qui n'est pas le cas entre Python 2 et Python 3.

yaugJe suis en train d'installer python et mon environnement sur mon serveur de prod, et après avoir mis à jour pip, bim, je me mange ça. Je vais trouver une solution en googlant le problème.. mais vraiment, j'ai une mauvaise impression sur l'environnement python et sa stabilité.

C'est une bonne pratique d'installer pip sur un serveur de prod ? ça devrait pas juste servir au dependency management en dev jusqu'à une release qu'on peut packager en embarquant les dépendances ?

bonne pratique, pas sur justement :)
J'utilise cela comme j'utilise composer pour php, c'est sans doute un tort oui.

yaugJ'utilise cela comme j'utilise composer pour php, c'est sans doute un tort oui.

Ben justement, je demande car par le passé j'ai dézingué pas mal de gens qui voulaient absolument installer composer en prod

j'aurais eu le même réflexe avec pip mais il fait ptet des trucs que je ne connais pas, où c'est ptet plus compliqué de packager du python que du php.

Pip est livré avec Python dans la librairie standard. Donc on peut toujours l'utiliser comme module via python -m pip ou quelque chose du genre. Il fait grosso-modo le même job que Composer (sans entrer dans les détails, y a quelques subtilités de plus dans pip). Pour l'essentiel, de toute façon, l'installation des paquets Python n'est pas géré par pip mais par des outils (aussi livrés en standard) tels que setuptools ou easy_install. Pip est, grosso-modo, juste un wrapper (très complet) au dessus de ces outils, ainsi qu'un outil de résolution de dépendances (et il le fait mal dès que ça touche aux dépendances transitives, et ça n'est pas prêt de changer, vu la lenteur avec laquelle le problème est attaqué).

De façon générale, c'est bien plus compliqué de packager du Python que du PHP. La faute a des tonnes de trucs introduits pour des raisons historiques. La grosse différence vient aussi du fait que Python peut installer les paquets "globalement" (même au sein d'un environnement virtuel), là où, si je ne m'abuse, Composer "vendorize" les dépendances (un peu à la "node_modules" pour le coup).

GuybrushLa grosse différence vient aussi du fait que Python peut installer les paquets "globalement" (même au sein d'un environnement virtuel), là où, si je ne m'abuse, Composer "vendorize" les dépendances (un peu à la "node_modules" pour le coup).

Il peut faire les deux. Mais l'installation globale est plutôt utilisée pour installer des dépendances de dév (phpunit, phpcs, etc...).
Pour une install en prod il vaut vraiment mieux englober le vendor/ dans le package et traiter celui-ci comme un binaire, c'est à dire le déployer à l'identique sur les environnements de QA jusqu'à la prod.

Des gens tiennent à faire leur composer install en prod et c'est presque un antipattern (ah tiens faut que j'installe git sur mon serveur de prod, ah tiens faut que je mette un token github, ah tiens il y a une dépendance qui s'installait bien en QA mais plus dispo au moment où j'installe ma prod, bon je vais passer un composer update en prod ni vu ni connu...)

La plupart des autres package managers proposent une sorte de "freeze" de l'environnement pour ces cas-là (par exemple, les lock files en Ruby ou npm, le requirements.txt en Python, etc.). Cela permet de déployer *exactement* les versions pinnées des dépendances, et donc de "cloner" son environnement vers la prod. Deux soucis (dont tu parles déjà) :
1. Il faut que les packages soient accessibles (soit sur le repository officiel, soit via git ou autre, et dans ce cas, mêmes soucis que ce dont tu parles) ;
2. Il faut que le paquet n'ait pas changé (parce que certains systèmes autorisent à modifier une version *déjà* déployée, et donc taper "nom_du_paquet == 1.0.0" ne garantit pas d'avoir le même code en fonction du moment de l'installation. Enfin, c'est plutôt rare quand même que ça marche pas )

En PHP, je sais que "vendoriser" les dépendances est une bonne pratique, et on conseille souvent pour les apps à passer en prod de le faire (et donc effectivement de "copier" le contenu du "vendor"). Dans d'autres langages (par ex JS avec npm, ou Python avec pip & co), c'est plutôt déconseillé (et on passe par les lock files du coup).

Bon, intéressantes toutes ces discussions aujourd'hui.
Pour la prod PHP, vu que je commite le fichier .lock de symfony (bonne pratique justement), cela me sert à freezer ma prod, le composer install se servant uniquement du .lock.

mais je vais creuser ce freeze total, c'est tellement pas bête que le cancre informatique que je suis n'y avais point pensé.