Pipenv: Le verrouillage est lent (et effectue des téléchargements redondants)

@colllin Avez-vous vérifié si les commandes pip qui contactent le serveur - comme pip search (je pense) - sont également lentes ?

Je vois un comportement similaire, mais c'est une sorte de problème connu et dépendant du réseau. Pour une raison quelconque, l'accès à pypi.org depuis mon réseau professionnel est incroyablement lent, mais il est normalement rapide depuis mon réseau domestique. Je pense que le verrouillage fait beaucoup de transactions pip sous le capot, donc un accès lent au serveur ralentit beaucoup l'opération.

EDIT : il se peut aussi que vous ayez juste beaucoup de sous-dépendances à résoudre - quelle est la taille de l'environnement une fois créé (par exemple, combien de packages de niveau supérieur dans votre pipfile et combien de packages retournés par pip list une fois l'environnement amorcé) ?

Merci pour la réponse réfléchie.

pip search n'est pas particulièrement rapide ou lent pour moi... ~1 seconde ?

Excusez-moi pour mon manque de connaissance du domaine : a-t-il vraiment besoin de pip search ? N'a-t-il pas tout installé ? N'a-t-il pas juste besoin d'écrire ce qui est déjà installé ? Ou... puisqu'il garantit de toute façon l'existence du fichier de verrouillage, pourrait-il le faire pendant qu'il installe les packages, ou avant ?

Je suppose que pipenv utilise pip sous le capot ? donc le processus d'installation est une boîte noire, et il ne peut pas connaître le graphique de dépendance de ce qui a été/sera installé sans faire ~une recherche de pip~ ses propres requêtes de pip ?

EDIT : il y a 1 package de niveau supérieur et environ 65 packages renvoyés par pip list dans ce référentiel particulier.

Je ne suis pas un contributeur au projet et pour le moment je ne connais pas tous les détails, mais je crois comprendre que la phase de verrouillage est celle où toutes les dépendances sont résolues et épinglées. Donc, si vous avez un package de niveau supérieur avec ~ 65 dépendances, c'est pendant la phase de verrouillage que toutes les dépendances de ce premier package sont (récursivement) découvertes, puis l'arbre de dépendance est utilisé pour résoudre quels packages doivent être installés et (probablement) dans quel ordre approximatif ils doivent être installés. Pas aussi sûr de la dernière partie.

Si vous effectuez une installation pip à partir d'un fichier Pipfile sans fichier de verrouillage, vous remarquerez qu'il effectue la phase de verrouillage avant d' installer les packages dans le fichier venv. De même si vous avez un fichier de verrouillage mais qu'il est obsolète. Je soupçonne qu'avoir un fichier de verrouillage et l'installer à l'aide de l'option --deploy serait plus rapide, tout comme l'option --no-lock ; dans le premier cas, vous obtenez une erreur si le fichier de verrouillage est obsolète, dans le second, vous perdez la division logique des packages de niveau supérieur (environnement déclaré) et l'environnement réellement installé (verrouillé) de tous les packages. C'est du moins ainsi que je le comprends.

Que pipenv utilise ou non pip sous le capot - je pense que oui - il doit toujours obtenir les informations du ou des serveurs pypi sur les dépendances des packages et autres, donc ma question sur la recherche pip était plus un proxy pour savoir à quelle vitesse ou ralentir votre chemin vers le serveur pypi n'est qu'une implication directe du mécanisme par lequel pipenv fait son travail.

Une expérience intéressante pourrait être de comparer le temps requis pour verrouiller l'arbre de dépendances dans pipenv et installer les exigences dans un nouveau venv en utilisant pip install -r requirements.txt . Je pense qu'ils devraient faire des choses assez similaires pendant la phase de résolution des dépendances.

Avons-nous établi quelque part qu'il y a des téléchargements redondants en passant ? Je suppose que c'est le cas, mais prouver que ce serait vraiment utile

Pour info, comparer pip install -r requirements.txt au temps qu'il faut pour verrouiller un graphique de dépendance ne sera pas informatif comme point de comparaison. Pip n'a pas réellement de résolveur, pas vraiment. Je pense que je peux décrire la différence. Lorsque pip installe votre requirements.txt , il suit ce processus de base :

• Trouvez la première exigence répertoriée
  
  
  
  • Trouver toutes ses dépendances
  
  
  • Installez-les tous
  
  
• Trouvez la deuxième exigence répertoriée
  
  
  
  • Trouver toutes ses dépendances
  
  
  • Installez-les tous
  
  
• Trouvez la troisième exigence répertoriée
  
  
  
  • Trouver toutes ses dépendances
  
  
  • Installez-les tous
  
  

Cela s'avère assez rapide car pip ne se soucie pas vraiment si les dépendances du _package 1_ sont en conflit avec les dépendances du _package 3_, il vient d'installer celles du _package 3_ en dernier, c'est donc ce que vous obtenez.

Pipenv suit un processus différent : nous calculons un graphique de résolution qui tente de satisfaire _toutes_ les dépendances que vous spécifiez, avant de créer votre environnement. Cela signifie que nous devons commencer à télécharger, comparer et souvent même des packages _building_ pour déterminer à quoi votre environnement devrait finalement ressembler, tout cela avant même d'avoir commencé le processus réel de l'installer (il y a beaucoup de billets de blog sur pourquoi cela c'est le cas en python donc je n'y reviendrai pas plus ici).

Chaque étape de ce processus de résolution est rendue plus coûteuse en termes de calcul en exigeant des hachages, ce qui est une bonne pratique. Nous hachons les paquets entrants après les avoir reçus, puis nous les comparons aux hachages auxquels PyPI nous a dit que nous devrions nous attendre, et nous stockons ces hachages dans le fichier de verrouillage afin qu'à l'avenir, les personnes qui souhaitent créer un environnement identique puissent le faire avec la garantie contractuelle que les packages à partir desquels ils construisent sont les mêmes que ceux que vous avez utilisés à l'origine.

La recherche de pip est une mauvaise référence pour tout cela, en fait, n'importe quel outil de pip est une mauvaise référence pour faire ce travail - nous utilisons pip pour chaque élément, mais en le rassemblant de concert et à travers de nombreuses dépendances pour former et gérer environnements et graphiques est l'endroit où la valeur de pipenv est ajoutée.

Un point de clarification - une fois que vous avez résolu le graphique de dépendance complet, l'ordre d'installation ne devrait plus avoir d'importance. Sous le capot, nous passons en fait --no-deps à chaque installation de toute façon.

En guise de petite remarque, la recherche pip est actuellement le seul élément de l'outil de pip qui repose sur l'interface XMLRPC désormais obsolète, qui est impossible à mettre en cache et très lente. Il sera toujours plus lent que toute autre opération.

Le verrouillage de numpy (et rien d'autre) prend 220 s sur ma machine (voir ci-dessous). La plupart du temps semble être passé à télécharger plus de 200 Mo de données, ce qui est assez déroutant étant donné que l'ensemble de la source numpy a 4 Mo. Bien que clairement, même si cela a été instantané, il reste encore 25 s de traitement réel, et même cela semble excessif pour calculer quelques hachages. Le verrouillage ultérieur, même après la suppression de Pipenv.lock, prend 5 s.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpy devrait être considérablement plus rapide maintenant (j'ai utilisé votre exemple comme cas de test en fait !). Lors de mon test le plus récent, je l'avais à ~ 30s sur un cache froid sur une machine virtuelle.

Pouvez-vous confirmer des améliorations avec la dernière version ?

Cela s'est considérablement amélioré pour moi aussi. Je suis maintenant assis sur une connexion très rapide, et je suis descendu jusqu'à 14 s, mais c'est à ce moment-là que le téléchargement est passé à 30 Mo/s. Qu'est-ce qui est téléchargé à part une seule copie du code source de numpy ?

Je pense que nous téléchargeons des roues redondantes (pas sûr). Nous évaluons déjà la situation.

J'ai radicalement changé mon Pipfile.lock en désinstallant quelques modifications et maintenant le déploiement sur une autre machine est gelé. Un correctif particulier pour cela?

Il n'est pas recommandé de modifier manuellement votre fichier de verrouillage. Sans plus d'informations, il n'est pas possible d'aider. Veuillez ouvrir un autre numéro.

Si vous souhaitez comparer les performances de pipenv lock, vous devriez essayer d'ajouter pytmx à vos dépendances...
pipenv lock prenait 1 heure ou plus pour nous (nous avons un internet assez lent), et après avoir supprimé pytmx, nous sommes descendus à environ 5 minutes et enfin pipenv est plus utilisable.
Je sais que pytmx est un gros paquet car c'est une grosse bibliothèque monolithique et dépend d'opengl/pygame et d'autres choses connexes, mais cela ne devrait pas prendre 1 heure pour verrouiller pipenv, quelle que soit la taille du paquet

Cela ne prend pas une heure pour moi

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

De plus, PyTMX fait moins de 20 Ko sur PyPI et n'a qu'une dépendance à six (ce qui est très petit), donc la mise en réseau ne devrait pas être un problème. Il se passe probablement autre chose dans votre environnement.

tu as raison c'est plus petit que ce que je pensais ça ne dépend pas explicitement de pygame et autres, je ne sais pas pourquoi ça prenait si longtemps alors !
Je vais essayer de trouver plus d'informations mais j'ai un processeur et un SSD de qualité supérieure, donc je pense toujours que le problème est lié à notre Internet lent

@techalchemy Je n'ai pas pipenv uninstall package_name et je les ai ensuite exécutés sur le serveur. Il est resté dans l'état verrouillé pendant très longtemps.

Je ne suis pas intéressé à dépenser de l'énergie sur cette discussion avec des plans aléatoires dans le noir. Veuillez fournir un cas de test reproductible.

Voici ce que j'espère être un cas de test reproductible
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Tenter de faire
pipenv install
dans ce référentiel sans verrouillage ont jusqu'à présent téléchargé plus de 700 Mo environ pendant son affichage
Locking [packages] dependencies...

Abandonnera dans un instant et recommencera avec --skip-lock jusqu'à ce que ce soit réparé

J'ai remarqué que lock était vraiment lent et téléchargeait une énorme quantité de données à partir de files.pythonhosted.org , plus de 800 Mo pour un petit projet qui dépend de scipy flask etc.

J'ai donc reniflé les requêtes adressées à files.pythonhosted.org , et il s'avère que pip ou pipenv effectuaient des téléchargements complètement inutiles, ce qui ralentit douloureusement lock .

Par exemple, la même version numpy avait été téléchargée plusieurs fois dans son intégralité. Et il a téléchargé des roues pour Windows / Linux, même si j'utilisais un Mac.

Ma configuration :

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

des Pipfiles supplémentaires sont-ils utiles pour le débogage ici ?

Très probablement @AlJohri , également toute information sur l'exécution des processus / verrous / io aiderait

Je suis coincé ici depuis environ 5 minutes déjà. J'ai d'abord pensé qu'il s'agissait peut-être d'une sorte de problème d'installation de pip et a tout réinstallé via Homebrew, mais toujours le même problème. Des idées pourquoi?

Enfin terminé après environ 6 à 7 minutes. Assez nouveau pour Python et Pipenv, donc un peu d'aide pour savoir où trouver les fichiers nécessaires au débogage serait génial ! :)

c'est assez mauvais au point que j'ai peur d'installer de nouvelles bibliothèques python ou de mettre à niveau celles existantes.

Après avoir regardé l'une des présentations du créateur, j'ai décidé d'utiliser pipenv . Mais c'est trop lent.

Merci pour vos commentaires éclairés.

@techalchemy S'il y a quelque chose que je pourrais faire pour aider et résoudre ce problème. Je suis très heureux de contribuer.

J'ai remarqué que lock était vraiment lent et téléchargeait une énorme quantité de données à partir de files.pythonhosted.org , plus de 800 Mo pour un petit projet qui dépend de scipy flask etc.

J'ai un soupçon, bien que des preuves non concluantes, que scipy soit corrélé avec de très longs temps de verrouillage pipenv .

parfois très pénible, j'installe PyPDF2 et texttract; pipenv a pris environ 10 minutes pour se verrouiller.

La lenteur de pipenv entrave vraiment le processus de développement pour nous. Je conseille maintenant à tout le monde de s'en tenir à pip + virtualenv jusqu'à ce que ce problème soit résolu.

des nouvelles à ce sujet? Un moyen d'aider ?
dupe de https://github.com/pypa/pipenv/issues/1914

/ edit : au fait, pourquoi pipenv install jour les versions dans le fichier de verrouillage ? o.Ò Je viens de l'exécuter après l'expiration du délai de verrouillage et maintenant que je regarde le nouveau fichier de verrouillage, je vois que les pandas ont été mis à jour de 0.23.4 à 0.24.0, numpy de 0.16.0 à 0.16.1, etc... Didn ne vous attendez pas à ce que cela se produise à moins que je ne fasse pipenv update ...

Je trouve qu'il s'installe rapidement et se verrouille lentement, donc dès que vous recevez le message Installation Succeeded , vous pouvez continuer à travailler... à moins que vous ne vouliez installer autre chose...

... ou besoin de pousser le fichier de verrouillage dans un référentiel.

install devrait-il de toute façon effectuer un verrouillage, étant donné que lock est déjà une commande distincte ? En attendant, la description de l'option install devrait spécifier que le verrouillage a également lieu, et peut-être même recommander --skip-lock .

Aussi, que diriez-vous d'épingler ce problème?

Pipenv est un outil vraiment merveilleux et j'avais l'habitude de le recommander, mais un projet avec 8 modules ne peut pas se verrouiller... il expire juste. Il ne semble pas y avoir d'intérêt à résoudre ce problème et c'est très frustrant. J'ai lu que vous pouvez obtenir des dépendances sans télécharger à partir de pypy maintenant, est-ce une solution de contournement pour ce problème? Ne voyez aucune discussion sur cette option ici. Pour le moment, l'outil est inutilisable pour mes besoins.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

En quoi n'est-ce pas la priorité principale de ce projet ? Pipenv est si lent qu'il est pratiquement inutilisable. Non seulement dans certains cas d'utilisations rares, il est toujours très lent.

Sans trop savoir ce qui se passe sous le capot, je pensais que cela pourrait être bien résolu avec un cache local du graphe de dépendance.

Pensez-y : si nous mettons en cache ce package x-1.2.3 dépend de y>=3.4 , nous pouvons effectuer localement une grande partie du travail actuellement effectué en téléchargeant les packages un par un, en les développant et en vérifiant les dépendances . La phase lock serait alors aussi simple que :

• Comparez le Pipfile au cache et assurez-vous que nous avons tout ce dont nous avons besoin.
• Sinon, téléchargez quelque chose de nouveau et calculez les dépendances là-bas
  
  
  
  • Cachez les modifications
  
  
• Installer.

Dans tous les cas, alors que la première fois peut être lente, les serrures suivantes seraient indolores, non ?

J'ai juste décidé d'utiliser pipenv au lieu de pip pour un petit projet. La première chose que j'ai faite a été de pipenv install -r requirements.txt . Il verrouille les dépendances depuis environ 10 minutes maintenant. Par conséquent, je vais revenir à pip.

Les gars, ce problème vous coûte beaucoup d'utilisateurs. Je propose d'y remédier rapidement.

Dans mon cas, l'installation des dépendances sur le serveur bloque le serveur pendant des heures. J'utilise l'instance AWS EC2 t2.micro avec 1 Go de RAM. Cette quantité de RAM est suffisante pour une seule application avec peu de dépendances, mais l'installation prend toute la mémoire et il n'y a qu'une seule façon de la faire fonctionner en redémarrant le serveur.

Ce problème est en suspens depuis de si longues années et aucune solution n'a été apportée à ce problème. Je vois plusieurs problèmes être fermés sans aucune résolution.

Un si bel outil négligé. Je vais me désinscrire de ce problème car je vois qu'il ne sera jamais résolu. Sera s'en tenir à quelque chose comme conda ou le faire manuellement en utilisant virtualenv.

Je suppose que je vais essayer https://github.com/sdispater/poetry :|

Un administrateur peut-il gentiment fermer ce fil aux commentaires ? Il semble qu'aucun contenu supplémentaire utile ne soit ajouté à la discussion.

Je serais heureux de souscrire un ticket de suivi du travail vers la résolution du problème.

Merci!

Je soupçonne que 99% des personnes utilisant cet outil et se plaignant sur ce fil sont des programmeurs. Au lieu de pleurnicher, mettez votre temps à dire et soumettez un PR.

Bonjour @idvorkin ,

J'ai essayé une fois .
Il a fallu des semaines pour réaliser la fusion du correctif trivial .
Il suffit de comparer le nombre de discussions avec la taille réelle du correctif.

Je ne veux définitivement plus soumettre de correctifs à ce projet.

Donc, votre conseil n'est pas aussi viable que vous pouvez le supposer.

@Jamim au nom des nombreux utilisateurs (et je soupçonne également les administrateurs), merci pour vos contributions. J'ai lu votre PR, et je pourrais sympathiser avec la frustration. Cependant, je dois être d'accord avec @techalchemy sur celui-ci :

Bien sûr, nous nous soucions de la bibliothèque que nous maintenons, mais je dirais que la formulation n'est probablement pas le moyen le plus efficace d'avoir une interaction positive.

Je n'ai jamais rencontré les administrateurs, mais s'ils sont comme moi (et peut-être vous), ce sont des humains avec une vie bien remplie dont la vie est remplie d'engagements avant même d'avoir de l'énergie à consacrer à ce projet.

De même, je parie que si vous (ou quelqu'un d'autre) résolviez le problème de performances, vous auriez un grand nombre de personnes qui vous aideraient à le développer, le tester, le fusionner ou, si nécessaire (et je doute fortement que ce le soit) créer un fork .

Je suis reconnaissant pour le temps que les développeurs de ce projet consacrent à cela, mais je suggère qu'il soit averti en gras que ce projet n'est pas encore prêt pour la production juste au-dessus des témoignages d'utilisateurs dans README.md , actuellement c'est tromper les gens pour qu'ils passent un temps précieux à remplacer leur pile pip/virtualenv actuelle par pipenv jusqu'à ce qu'ils découvrent ce verrouillage lent et qu'ils comprennent qu'ils ne peuvent pas l'utiliser.

jusqu'à ce qu'ils découvrent ce verrouillage lent et qu'ils comprennent qu'ils ne peuvent pas l'utiliser.

Bien que je serais très heureux d'obtenir une accélération car elle est en effet très lente, il n'y a pas besoin d'une telle hyperbole.

J'utilise très bien pipenv tous les jours. Les améliorations du flux de travail qu'il fournit l'emportent largement sur la lenteur occasionnelle. Le verrouillage n'est tout simplement pas quelque chose que je fais tout le temps, contrairement à l'exécution de scripts par exemple.

À quelle fréquence verrouillez-vous que cela devient un problème tel que vous sentez que vous ne pouvez pas l'utiliser ? :bouche ouverte:

@bochecha ma déclaration peut être une hyperbole à votre avis mais c'est un fait basé sur mon expérience, j'ai entendu parler de pipenv par certains collègues, aujourd'hui j'ai essayé de mettre à jour un ancien projet, de mettre à jour ses dépendances, etc. pipenv dans le cadre du processus de mise à jour. Je devais mettre à jour une dépendance, vérifier comment les choses fonctionnent avec elle, des pièces de mise à jour de code si nécessaire, puis mettre à jour une autre dépendance, chaque fois que je courais pipenv install <something> je devais attendre un temps ridiculement long, d' abord je pensais que c'est le calcul quelque chose et il le mettra en cache pour l'avenir car je ne pouvais pas croire que c'était un problème pour prétendre être un gestionnaire de packages prêt pour la production. Après avoir installé ~ 10ème package, j'ai commencé à chercher à ce sujet et j'ai trouvé ce fil, j'ai supprimé Pipfile et Pipfile.lock et je suis revenu à mon flux de travail pip/virtualenv. J'étais tenté d'essayer la poésie mais je ne pouvais pas risquer une heure de plus.

Ces choses se produisent dans la communauté JS par exemple mais je ne m'y attends pas dans la communauté Python, nous n'avons pas ce genre de problèmes dans notre communauté et nous devrions essayer de l'éviter, une clause de non-responsabilité dans README.md peut éviter ce désagrément donc je l'ai suggéré dans mon commentaire. Cela pourrait me faire gagner du temps aujourd'hui et je pense que cela fera gagner du temps aux autres nouveaux arrivants et ils n'auront pas une mauvaise expérience avec ce projet afin qu'ils puissent rester en tant que futurs utilisateurs potentiels.

Je suis plutôt d'accord avec sassanh. Tout le monde n'est pas touché de la même manière par le problème, mais certains d'entre nous ont été assez touchés. J'ai fait des projets open source qui n'étaient pas vraiment entièrement fonctionnels ou prêts pour la production et quand c'était le cas, j'ai mis une clause de non-responsabilité afin de ne pas perdre le temps des gens s'ils ne sont pas prêts pour les bosses.

Je ne suis pas en colère contre les personnes qui travaillent sur ce projet, mais je suis un peu en colère contre la personne qui en a parlé en public, le vendant comme un excellent outil avec 0 avis de non-responsabilité. En conséquence, j'ai perdu pas mal de mon temps précieux à essayer de faire fonctionner un outil, dans l'espoir de gagner du temps à long terme, mais j'ai fini par devoir revenir à pip et à mon propre script, car pipenv ne fonctionnait pas dans mon environnement limité en temps et en bande passante.

chaque fois que j'ai exécuté pipenv install

Saviez-vous que pipenv install -r requirements.txt peut verrouiller/installer qu'une seule fois à partir de votre projet existant lorsque vous essayez de le déplacer vers pipenv ? Si vous ne le faites pas, le problème pourrait être un problème de documentation ?

Avant tout, je suis certain que pipenv sera un bon remplacement pour le flux de travail pip/virtualenv, je suppose que nous savons tous que nous en avons besoin et je pense que le jour où pipenv sera prêt pour la production, il sera d'une grande aide pour de nombreuses personnes/projets.

@bochecha comme je l'ai expliqué, je devais installer une version plus récente d'un package, faire certaines choses, puis passer au package suivant, peut-être que si je faisais ce processus avec pip puis migrais vers pipenv, je ne remarquerais pas du tout le problème, mais j'ai d'abord migré vers pipenv, puis j'ai mis à jour les packages un par un et c'était vraiment ennuyeux. Je suis content que cela fonctionne pour votre cas d'utilisation, mais je suis sûr que cela ne fonctionne pas pour beaucoup de gens comme moi (jetez un œil aux commentaires ci-dessus). Il devrait être mentionné dans le README.md , au moins il devrait être mentionné que "chaque verrouillage peut prendre beaucoup de temps, donc si votre cas d'utilisation inclut l'installation/suppression rapide de nombreux packages, vous devriez éviter d'utiliser pipenv jusqu'à ce que ce problème soit résolu" (encore en gras, et en plus des témoignages) si vous annoncez les problèmes avant que tout le monde n'en soit affecté, tout le monde sera reconnaissant, si les problèmes affectent les autres et que vous ne les avez pas prévenus, tout le monde se mettra en colère.

D'accord. J'ai commencé à m'intéresser à la poésie et même à ajouter un autre utilisateur à mon système d'exploitation par projet au lieu d'utiliser à nouveau pipenv. Si cela ne fonctionne pas bien pour les cas d'utilisation occasionnels avec les paramètres par défaut, c'est cassé à mon humble avis .
C'est un outil super utile ! Il y a juste cette chose qui le rend super inutile pour moi. Et malheureusement j'ai peu de temps pour contribuer :|

Bien sûr, il est ennuyeux d'attendre un verrou lorsque vous devez effectuer plusieurs installations en cours de session de développement, mais cela peut être géré.

L'important est qu'un fichier de verrouillage soit généré avant de transmettre les modifications locales au référentiel. J'utilise judicieusement le drapeau —skip-lock pendant les sessions de développement, et pipenv lock une fois à la fin avant de m'engager.

Merci pour le projet. Mais,
Le verrouillage est verrrrrrrrrrrrrrrrrrrrrrrrrrrrr lentwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
Cet env rend le verrouillage plus rapide, s'il a déjà un cache de paquet pip installé.

Salut @yssource et tout le monde,

Merci pour le projet. Mais,
Le verrouillage est verrrrrrrrrrrrrrrrrrrrrrrrrrrrr lentwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

Ce projet semble être mort, donc si vous souhaitez éliminer le problème de vitesse, envisagez de migrer vers Poetry, qui est beaucoup plus rapide.

@Jamim , merci d'avoir suggéré la poésie. Personnellement, pour une raison quelconque, je ne l'ai pas rencontré. Après avoir lu son readme, cela semble valoir la peine d'essayer. Il répertorie également certains avantages par rapport à Pipenv (https://github.com/sdispater/poetry/#what-about-pipenv).

Cela dit, le projet étant mort est une grossière exagération, et si j'étais à la place des auteurs de pipenv, je trouverais cela irrespectueux. L'auteur a répondu dans la section des problèmes hier. C'est juste ce problème de verrouillage qui est négligé, probablement parce qu'il est difficile à résoudre.

Pour mémoire, Poetry souffre également de problèmes de performances :
https://github.com/sdispater/poetry/issues/338

J'ai le même problème dans tous mes projets.
La cause semble être pylint.
Pipenv (pip) peut l'installer avec succès, mais le verrouillage prend une éternité !
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

J'ai beaucoup entendu parler de pipenv et je l'ai essayé aujourd'hui,
le verrouillage est également très lent pour moi. Cela fait déjà environ 2 minutes, toujours bloqué sur le verrouillage.
Le téléchargement est assez rapide, mais le problème vient du verrouillage.
Ce problème est-il résolu ?
J'utilise Pop os 19.10, pipenv, version 11.9.0 d'apt, python 3.7.5.

Je souhaite attirer l'attention sur cet excellent commentaire de #1914 sur le même sujet https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 qui suggère que le téléchargement et l'exécution de chaque dépendance ne sont plus nécessaires.

Je me demande si des développeurs pourraient commenter la faisabilité de cette approche.

J'ai remarqué qu'il est en fait plus rapide de supprimer l'environnement et de le recréer à partir de zéro pour mettre à jour le fichier de verrouillage.
Cela est vrai à la fois pour exécuter pipenv lock et pipenv install some-package

J'aime vraiment pipenv mais pas autant que j'aime ma bande passante et mon temps. Je finis donc par résoudre le problème en utilisant:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

Je souhaite bonne chance aux développeurs...

@ravexina merci pour la suggestion, je vais essayer à coup sûr