La finalité de pipenv est différente, il sert plutôt gérer les dépendances d'un projet, un requirements.txt amélioré en somme. Sauf que ça n'est pas adapté pour le développement de bibliothèques, uniquement d'applications distribuables, c'est parmi d'autres raisons pourquoi je lui préfère poetry (que j'ai utilisé pour pipis).
Pipis c'est totalement autre chose, c'est juste pour isoler un paquet et ses dépendances dans un venv, et ça link le ou les exécutables du paquet (et pas de toutes se dépendances) dans ~/.local/bin/. En gros tu installes Ansible, et il n'y a que lui qui est « exposé » au système, ses dépendances sont dans un venv dédié. Comme ça évite de pourrir ton système avec les dépendances de tout les paquets que tu installes (ansible, awscli, openstack, etc.), et ça évite les éventuels conflits de dépendances entre ces différents paquets.
Posté par NiKaro (site web personnel) .
Évalué à 2.
Dernière modification le 23 mai 2018 à 13:20.
Ah mais du coup c'est clairement NIH, c'est inspiré (voire une réécriture) de pipsi qui fait exactement la même chose avec compatibilité Python 2, Windows, et qui utilise virtualenv au lieu de venv.
Je n'aimais pas virtualenv, qui copie les binaires Python, tandis que venv les link simplement, en plus d'être intégré dans la bibliothèque standard. Je ne voulais pas me préoccuper de Python 2 et Windows. J'ai essayé de coller davantage à la CLI de pip, et d'ajouter des fonctionnalités qui manquaient à mon sens. Puis c'était l'occasion pour moi de me faire la main sur un projet de A à Z, à la base je suis plutôt adminsys que dev.
# Et pipenv ?
Posté par Glandos . Évalué à 2.
Ah oui, ça fait un peu NIH, mais pourquoi pas.
Et j'ai pas compris la différence avec pipenv. Bon, OK, j'ai pas pris le temps de chercher la différence.
[^] # Re: Et pipenv ?
Posté par NiKaro (site web personnel) . Évalué à 3.
NIH ?
La finalité de pipenv est différente, il sert plutôt gérer les dépendances d'un projet, un
requirements.txtamélioré en somme. Sauf que ça n'est pas adapté pour le développement de bibliothèques, uniquement d'applications distribuables, c'est parmi d'autres raisons pourquoi je lui préfère poetry (que j'ai utilisé pour pipis).Pipis c'est totalement autre chose, c'est juste pour isoler un paquet et ses dépendances dans un venv, et ça link le ou les exécutables du paquet (et pas de toutes se dépendances) dans
~/.local/bin/. En gros tu installes Ansible, et il n'y a que lui qui est « exposé » au système, ses dépendances sont dans un venv dédié. Comme ça évite de pourrir ton système avec les dépendances de tout les paquets que tu installes (ansible, awscli, openstack, etc.), et ça évite les éventuels conflits de dépendances entre ces différents paquets.[^] # Re: Et pipenv ?
Posté par Glandos . Évalué à 3.
Not Invented Here
C'est parce que ça me semblait être un besoin déjà couvert par des programmes existants. Mais les explications sont beaucoup plus claires comme ça :)
[^] # Re: Et pipenv ?
Posté par NiKaro (site web personnel) . Évalué à 2. Dernière modification le 23 mai 2018 à 13:20.
Ah mais du coup c'est clairement NIH, c'est inspiré (voire une réécriture) de pipsi qui fait exactement la même chose avec compatibilité Python 2, Windows, et qui utilise virtualenv au lieu de venv.
Je n'aimais pas virtualenv, qui copie les binaires Python, tandis que venv les link simplement, en plus d'être intégré dans la bibliothèque standard. Je ne voulais pas me préoccuper de Python 2 et Windows. J'ai essayé de coller davantage à la CLI de
pip, et d'ajouter des fonctionnalités qui manquaient à mon sens. Puis c'était l'occasion pour moi de me faire la main sur un projet de A à Z, à la base je suis plutôt adminsys que dev.# Cool, ça va me simplifier
Posté par Alex G. . Évalué à 2.
Je faisait un peu la même chose à la mano, là ça va me simplifier le boulot. Merci !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.