Hello tout le monde,
je découvre aujourd’hui, via le Pycoders Weekly, le projet pipenv, qui est présenté ici comme l’outil de gestion de packages officiellement recommandé.
Un peu surpris, et en parcourant rapidement quelques pages de docs, je lis, sur la doc officielle :
While pip alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it’s a higher-level tool that simplifies dependency management for common use cases.
En regardant un peu ce que ça fait, j’ai l’impression d’y voir une philosophie très proche de npm : un gestionnaire de dépendance de projet, qui vient tirer des dépendances locales.
Node et Python ont pourtant une différence de paradigme fondamentale concernant les environnements. Là où Python va installer les librairies au niveau du système, en utilisant le PYTHONPATH pour retrouver ses petits, node, de part l’historique du langage, va par défaut télécharger les dépendances dans le répertoire courant (le fameux node_modules) à moins qu’on l’invite à installer un package de manière global, dans le but d’utiliser une application au niveau système, sans que ça ait rapport avec un projet (newman, vue-ui, etc).
Les environnements virtuels de python ont beau ressembler à un répertoire node_modules, ce n’est pas du tout le même concept, puisque le principe consiste peu ou prou à tricher sur les variables d’environnements pour installer les dépendances à un autre endroit sur le système.
Et par là même, ça ne remplit pas le même rôle. Virtualenv crée des environnements python différents, avec son propre interpréteur, ses propres librairies.
Le fonctionnement de pip n’est pas affecté par virtualenv, il fonctionne comme il le ferait en “global”, il n’a pas conscience d’être dans un virtualenv.
Et ça permet du coup de faire des choses super intéressantes, avec des environnements contextuels, qui, du coup, ne se contentent pas de simplement décrire les dépendances de mon petit projet Django, mais peuvent aussi préparer et documenter (un minimum) l’environnement python dans lequel on va se trouver. Dans les faits, on voit souvent des projets avec ces niveaux de dépendances :
- requirements/base.py
- requirements/dev.py
- requirements/jenkins.py
- requirements/prod.py
- requirements/doc.py
avec l’environnement de développement qui tire les dépendances de base et de la doc, l’env de prod qui vient tirer du gunicorn et d’autres paquets dont on a pas besoin à la maison, l’environnement jenkins qui va aussi tirer la doc, etc.
Beaucoup de souplesse, qu’on ne retrouve pas avec pipenv, puisqu’il semble qu’il n’y ait que des dépendances générales et des dépendances de dev. C’est un peu léger et surtout ça ressemble comme deux gouttes d’eau à ce qu’on voit côté npm.
J’ai spontanément quelques questions sur le sujet :
- Quels sont les problèmes rencontrés avec une utilisation de pip (dans un virtualenv ou non) que pipenv se propose de régler ?
- J’ai vraiment le sentiment que c’est pour coller à ce qui se fait ailleurs, indépendamment des spécificités du fonctionnement du langage. Est-ce que ce n’est pas faire une erreur de vouloir reproduire ce qui se fait chez node alors que la gestion de l’installation des librairies est vraiment différente ? C’est pour rendre l’explication des dépendances dans python plus compréhensibles pour des développeurs qui travaillent moins proche du système et qui ont des habitudes ailleurs ?
- Est-ce qu’il n’y a pas un distinguo à apporter entre package manager, gestionnaire d’environnement, et gestionnaire de dépendance projet ?
- Comment est-ce que pipenv va me rendre plus heureux, alors que finalement je n’ai jamais eu aucune douleur à utiliser pip et les virtualenv ces 10 dernières années ?
) j’ai laissé tomber 