Deux bibliothèques python du même nom, deux versions différentes, une seule installation sur mon ordinateur : il ne pouvait en rester qu'une, et elle a emporté mon script de météo dans sa chute avant d'abîmer aussi mon programme de recettes, faute d'un environnement virtuel pour organiser tout ça séparément.
Un environnement virtuel python, c'est la réponse que j'ai fini par adopter face à ce genre de collision, en auto-formation et sans grande théorie derrière moi : une bulle séparée par projet, où chaque bibliothèque installée reste isolée du reste de l'ordinateur, sans venir écraser ce qu'un autre script utilise déjà.
Pourquoi mélanger ses projets python finit toujours mal
Avant de connaître ce système, j'installais tout au même endroit, dans le même grand fourre-tout numérique, un peu comme si je rangeais les épices, la farine et les produits de nettoyage dans le même placard sans étiquette. Chaque script récupérait ce qu'il trouvait sur place, et tant que les besoins ne se croisaient pas, ça tenait à peu près debout.
Ma première tentative pour comprendre pourquoi tout s'effondrait a été de suivre un manuel technique en anglais, trouvé un peu au hasard, pensé pour des gens qui savaient déjà coder depuis longtemps. Je n'ai pas tenu deux chapitres : trop de vocabulaire supposé acquis, trop de raccourcis, aucune image du quotidien à laquelle me raccrocher. Je l'ai refermé sans regret et je suis repartie chercher des explications plus simples, adaptées à quelqu'un qui découvre tout ça après le travail.
Le problème, une fois qu'on le regarde de près, tient en une phrase : chaque projet a ses propres exigences côté modules, et un ordinateur qui n'a qu'une seule installation python ne peut satisfaire deux exigences contradictoires à la fois. En installant une version pour mon programme de recettes, j'écrasais celle dont mon script météo avait besoin, sans le savoir, sans le vouloir, et sans le moindre message d'alerte au moment où ça comptait.
Créer un environnement virtuel python, étape par étape
La commande qui règle ce problème tient sur une seule ligne : python -m venv mon_environnement, tapée dans le terminal une fois qu'on se trouve dans le dossier du projet concerné. Il faut évidemment avoir python déjà installé sur la machine avant d'en arriver là, ce qui est une autre histoire à part entière, mais une fois cette étape passée, la commande crée un nouveau dossier qui ne contiendra que ce dont ce projet précis a besoin.
Sitôt lancée, elle fait apparaître un fichier discret, pyvenv.cfg, presque invisible au milieu des autres, qui indique à l'ordinateur quelle version utiliser ici et nulle part ailleurs. Rien de sorcier une fois qu'on l'a vu fonctionner une première fois, même si sur le moment, un dossier inconnu qui surgit tout seul a de quoi inquiéter n'importe quelle débutante.
Activer la bulle : windows, mac et linux ne parlent pas pareil
Créer le dossier ne suffit pas : encore faut-il l'activer pour que le terminal accepte d'y travailler. Sur mac ou linux, la commande est source venv/bin/activate. Sur windows, c'est .\venv\Scripts\activate, et confondre les deux fait perdre un temps fou à chercher pourquoi le terminal refuse une commande qui, sur l'autre système, aurait très bien fonctionné.
Une fois la bulle activée, installer un module externe comme pandas ou requests ne concerne plus que ce projet-là. C'est exactement à ce moment-là que pourquoi importer des modules python change tout quand on débute enfin prend tout son sens : on peut enfin le faire sans craindre de saboter un autre script au passage.
Comment savoir qu'on est bien dans son environnement ?
Le signe ne trompe pas : le nom de l'environnement s'affiche entre parenthèses au tout début de la ligne de commande, du genre (mon_environnement). Tant que cette mention reste là, tout ce qui s'installe ou se lance reste confiné à ce projet, comme une planche à découper réservée à un seul ingrédient qu'on peut laver et ranger sans que le reste de la cuisine en garde une trace.
Ça change aussi la façon d'aborder mes astuces pour déboguer son code python sans perdre patience le soir : quand un message d'erreur apparaît, on sait déjà qu'il ne vient pas d'un module mal installé ailleurs sur la machine, ce qui réduit d'un coup la moitié des pistes à explorer.
Faut-il créer un venv pour le moindre script ?
Non, et c'est probablement la seule chose sur laquelle j'ose avoir un avis tranché. Pour un script de trois lignes qui manipule une chaîne de caractères ou affiche un résultat, créer un environnement virtuel ajoute une couche de complexité sans rien apporter en échange : on se retrouve à se demander si un bug vient du code ou d'une activation mal faite, pour un script qui n'utilise même pas de module externe.
Ma règle, avec le peu d'expérience que j'ai : dès qu'un script a besoin d'un module qui ne fait pas partie de python de base, comme pandas ou requests, l'environnement virtuel devient utile. En dessous de ça, autant garder les choses simples et se concentrer sur le code lui-même.
Ce que je continue à tester à l'intérieur de ma bulle, pour organiser mon code
À l'intérieur de cet espace protégé, je continue à m'entraîner sur les bases : une variable qui change de valeur d'une ligne à l'autre, une boucle for qui tourne sans planter, une condition if / else qui prend la bonne décision, une liste qu'on trie ou qu'on parcourt, un dictionnaire pour associer un ingrédient à sa quantité, une chaîne de caractères qu'on découpe dans tous les sens, et de temps en temps un vrai bloc try / except quand je sais d'avance qu'un script risque de planter. Même les erreurs d'indentation, qui me faisaient hurler au début, deviennent plus faciles à repérer quand l'environnement autour est propre et qu'on peut écarter d'autres pistes.
Apprendre à créer des fonctions python pour arrêter de copier-coller et laisser un input() attendre patiemment que je tape quelque chose complètent la liste des habitudes que je garde d'un projet à l'autre, maintenant que chacun a sa propre bulle pour les accueillir sans se marcher dessus.
L'autre jour, une collègue m'a demandé de l'aide sur une formule Excel qui refusait de donner le bon résultat, et je me suis surprise à lui expliquer la logique comme s'il s'agissait d'une ligne de code, une condition ici, sinon ça part là. Ma voisine, elle, part courir en trail dans la Chaîne des Puys presque tous les week-ends, et je l'envie un peu, même si mes petites victoires à moi tiennent plus du terminal que du sentier.
Le radiateur qui se relance quelque part vers 22 h est en général mon signal pour refermer l'ordinateur, parfois en plein milieu d'un test, parfois après une petite marche aux Halles Saint-Joseph pour se vider la tête avant de reprendre. Je ne sais toujours pas si je crée trop d'environnements virtuels ou pas assez, et je ne suis pas certaine qu'il y ait une bonne réponse à cette question-là.