Un dossier.
Un dossier qui contiendra tout ce que tu vas installer avec pip.
Avantages : tu sais que ce que pip installe va dedans et uniquement dedans (pas un peu dans Program Files, un peu dans la base de registre, un peu par ci, un peu par là, non, rien en dehors du dossier. Donc pour tout désinstaller (quand on a tout cassé) c’est simple : supprimer le dossier.
Je suis preneur de toutes les explications
Ça se crée avec python3 -m venv depuis un émulateur de terminal.
Le truc noir, c’est ça, un émulateur de terminal. Sur Windows y’a cmd.exe mais je crois que Microsoft ne le maintient plus depuis qqch comme 13 ans. Sur Windows y’a aussi powershell mais personne n’y comprend rien vu qu’ils ont inventé une nouvelle syntaxe qui n’est compatible avec aucun autre shell.
Si tu veux un émulateur de terminal plus moderne tu as trois choix :
- Arrêter de croire ce que disent les commerciaux de chez Microsoft (je sais, c’est dur, ils sont forts !), et donc arrêter d’utiliser leur OS, installe une Debian ou une Fedora (ceci n’est pas un troll, 100% du top 100 des supercalculateurs tournent sur Linux, 96% des sites webs sont hébergés sur Linux, Android c’est un Linux).
- Garder Windows deux-trois jours de plus avant de craquer et utiliser WSL en attendant, WSL permet d’avoir une Debian (ou une Ubuntu ou un autre parfum de Linux) dans son Windows. Ça marche étonnamment bien.
- Garder Windows deux-trois jours de plus avant de craquer et utiliser git bash en attendant, git bash c’est minimaliste, il manque plein de trucs, c’est pas fait pour faire autre chose que du git, mais ça marche déjà mieux que
cmd.exequand même.
Je suis preneur de toutes les explications
OK tu as un émulateur de terminal de qualité maintenant, on peut dire terminal pour gagner du temps. Dans l’émulateur de terminal tu vois des caractères, qqch comme jean@tamachine $, ça s’appelle le prompt c’est bien le terminal qui est chargé de l’afficher (la partie bête et méchante, le "je mets le j là, le e là, …), mais c’est le shell qui décide quoi afficher. bash c’est un shell, c’est celui que tout le monde utilise (sauf deux-trois barbus au fond qui utilisent zsh, et deux-trois vieux là bas qui utilisent csh, tcsh, et le hipster devant qui utilise fish).
Le shell c’est celui qui exécute un programme quand tu tapes son nom. Tu tapes python3 il cherche, trouve, et exécute Python.
Ça ressemble à ça :
jean@tamachine $ python3
>>> print(42)
42
1ère ligne le prompt finit par $, tu tapes python3 et hop il exécute Python. Python affiche un prompt différent, >>> pour le reconnaître.
pip est un programme aussi, comme python, donc pour exécuter pip il faut écrire pip dans le shell (et pas dans Python, donc après $ mais pas après >>>).
Tous ces programmes ne fonctionnent qu’en ligne de commande, il n’y a pas d’interface graphique, pas de fenêtres, tu ne peux donc pas les exécuter en double-cliquant dessus, il faut vraiment les invoquer par leur nom via un shell dans un terminal.
Je suis preneur de toutes les explications
On a jamais d’interface graphique parce que c’est incohérent (deux programmes fenêtrés n’ont pas les mêmes raccourcis claviers, pas les mêmes design, …). En ligne de commande il existe une cohérence basée sur “tout ce qu’on manipule est du texte, tout programme peut lire ce qu’un autre programme écrit et ils se comprennent tous car c’est juste du texte”. Sur cette fondation par exemple on peut écrire un programme qui cherche dans du texte, et une fois qu’on l’a écrit, c’est terminé, on l’a, on peut l’utiliser (il s’appelle grep, il existe depuis 1973, on l’utilise toujours, il a été amélioré depuis, il est poli comme un galet ! Son nom est historique, je sais que tu veux toutes les explications mais je vais prendre un raccourci, désolé). Dans un monde fenêtré, applicatif, graphique toutes les applications doivent recoder leur propre “recherche” (celle de chrome, de Firefox, de word, de libreoffice, sont toutes différentes). Quelle perte de temps, d’énergie de recoder encore et encore les mêmes fonctionnalités. Et quel inconfort pour l’utilisateur d’avoir a ré-apprendre à chaque nouveau programme comment fonctionnent toutes ces briques élémentaires.
D’ailleurs un programme Python c’est du texte. C’est cohérent on peut utiliser grep pour chercher dans un fichier .py. Non, un document Word ce n’est pas du texte c’est du XML encodé en UTF-32 stocké dans un zip. Essaye un jour c’est amusant, renomme un .docx en .zip et tu peux le décompresser pour voyager dedans. Mais ce n’est pas du texte donc aucun autre programme ne peut comprendre aisément un fichier docx, bouh, saymal.
Donc, tu as un terminal moderne, et un shell, tu sais démarrer un programme en tapant son nom, pour quitter Python essaye exit().
Maintenant que tu as tout ça tu peux créer des venvs, autant que tu veux, ce sont juste des dossiers, ça se fait en appelant python3 -m venv .venv.
le .venv a la fin est libre, tu peux écrire python3 -m venv coucou, c’est le nom du dossier qui sera crée, mais les devs ça manque d’inspiration, alors on l’appelle tous .venv. Tellement que les éditeurs de code cherchent si par hasard ils trouvent un dossier .venv et s’il est là ils l’utilisent sans qu’on ai rien a leur dire, c’est pratique. Fais comme tout le monde, nomme tes venvs .venv.
Je suis preneur de toutes les explications
OK le point au début du dossier, c’est parce que sur Linux on a pas le "clic-droit → propriété → fichier caché », sur Linux c’est une convention, pas une case a cocher. La convention c’est : si le dossier commence par point, alors il est caché. Et vu que les venvs c’est pas le plus important dans un projet, on aime bien le cacher un peu.
Bon tu as un venv, peut-être même 10 maintenant, moi j’en ai parfois 100 a force de tester des trucs par-ci par là, démarrer un projet, un autre, un autre, … Un venv contient un Python et tout ce qui est installé pour lui via pip.
Donc il va falloir dire a tout ce système quel Python il doit utiliser, donc quel venv il doit utiliser ! La machine ne peut pas deviner…
Alors on ne va pas dire ça au terminal, il est bête, il ne sait que afficher des caractères, et on ne va pas dire ça a Python non plus : ça serait “trop tard” s’il est déjà lancé ce n’est peut-être pas celui du venv que tu voulais. Le seul moyen c’est de dire ça à ton shell (bash) via : source .venv/bin/activate.
Là le shell réagit un peu et rajoute (.venv) au prompt.
À partir d’ici tu peux travailler, installer, tout casser, réessayer, etc… si tout est cassé tu supprime le dossier .venv, recréer un venv, et hop tu as un système propre et fonctionnel pour travailler.
Au total ça ressemble à :
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ pip install opencv-python
Ne crée pas de fichier dans le dossier .venv/, c’est pour pip, pas pour ton code, n’oublies pas que tu peux être amené a le supprimer, donc ton code doit être dans un fichier à côté du .venv/ mais pas dedans.