Pipenv: La commande `pipenv install XYZ` se bloque parfois indéfiniment à "Verrouiller les dépendances [packages]"

Non pas que cela devrait arriver dans tous les cas, mais sur quel matériel l'exécutez-vous ?

@uranusjr Veuillez trouver le rapport d'information sur le matériel ci-joint.
hardinfo_report.txt

Cela se produit-il systématiquement ? Essayez pipenv lock —verbose —clear

@techalchemy , j'ai couru pipenv lock --verbose --clear , et les résultats sont similaires :

> pipenv lock --verbose --clear
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

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

Locking [packages] dependencies…

Il est resté accroché à "Verrouiller les dépendances [packages]".

Une chance de reproduire cela sur votre machine ? Avec tensorflow en particulier, ça m'arrive à chaque fois.

EDIT: j'ai testé cela sur l'ordinateur d'un ami. Il utilise Ubuntu 17.10 et il n'a pas rencontré le problème. Les deux ordinateurs sont sur le même réseau. Une différence entre son ordinateur et le mien est qu'il n'a installé que pipenv plutôt que pipenv et virtualenvwrapper. Je vais faire tourner une machine virtuelle pour voir si cela est en quelque sorte connecté à virtualenvwrapper et/ou aux variables d'environnement que j'ai définies et qui sont partagées entre les deux (c'est-à-dire $WORKON_HOME).

Je vois actuellement le même problème; ma sortie pipenv lock --verbose --clear ressemble exactement à celle de @MarenstainBear . J'utilise Ubuntu et j'utilise pyenv pour gérer virtualenvs.

hardinfo_report.txt

Je vois que vous avez installé Pipenv contre le système Python. Avez-vous pyopenssl (ou quelque chose d'autre lié à SSL, honnêtement, je ne m'en souviens pas, cela fait partie de requests[security] ) installé dans le même environnement? Ceci est connu pour rendre les opérations extrêmement lentes.

J'ai installé requests[security] et pyopenssl à l'intérieur du virtualenv juste pour être sûr, mais il est toujours suspendu. En déboguant plus loin, j'ai trouvé qu'il se bloque à l'intérieur venv_resolve_deps la deuxième fois, en particulier à la ligne 376, c = delegator.run(cmd, block=True) .

Ce qui est plus étrange, c'est que si j'exécute cette commande directement ( python resolver.py ), à partir de la ligne de commande, elle fonctionne parfaitement.

Oui, il semble que je le fasse, mais uniquement pour mon python 2, pas pour python 3 (et mon instance pipenv a été installée via la version python 2 de pip):

mary<strong i="6">@marvel</strong>:~$ /usr/bin/python2.7 -m pip freeze | grep -i ssl
pyOpenSSL==17.5.0
mary<strong i="7">@marvel</strong>:~$ /usr/bin/python3 -m pip freeze | grep -i ssl
mary<strong i="8">@marvel</strong>:~$ 

Je vais passer à mon autre ordinateur portable et dans certains environnements virtuels où je ne peux pas reproduire cela pour voir s'ils n'ont _pas_ pyOpenSSL.

EDIT : Suppression de quelques paragraphes sur un autre problème que je voyais. C'était mon erreur - j'étais en fait dans un sous-répertoire mais je ne m'en rendais pas compte car sans ma configuration zsh normale désactivée à des fins de test, je n'avais plus d'indicateur visuel dans mon invite de mon cwd. Comme @uranusjr l' a correctement déclaré "mais Pipenv fait beaucoup de détection d'environnement, et est connu pour fonctionner bizarrement dans un shell mal configuré."... J'avais en effet momentanément mal configuré mon shell.

@uranusjr
EDIT 2 : J'ai testé ceci sur une machine virtuelle avec une configuration assez similaire à ma machine hôte (y compris l'installation de pipenv sur un environnement python 2.7.12 contenant le module pyOpenSSL), et sur cette machine tout fonctionne parfaitement comme prévu. Cela me fait douter que pyOpenSSL soit le problème ici. (J'ai noté que la version de pipenv est plus élevée sur ma machine virtuelle, donc je pense que je vais mettre à jour pipenv localement pour voir si cela fait une différence.)

Version Pipenv : '11.9.0'

Emplacement de Pipenv : '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Emplacement Python : '/usr/bin/python'

Autres installations Python dans PATH :

• 2.7 : /usr/bin/python2.7
• 2.7 : /usr/bin/python2.7
• 3.5 : /usr/bin/python3.5m

• 3.5 : /usr/bin/python3.5

• 2.7.12 : /usr/bin/python

• 2.7.12 : /usr/bin/python2
• 3.5.2 : /usr/bin/python3

Informations PEP 508 :

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-36-generic',
 'platform_system': 'Linux',
 'platform_version': '#40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

Variables d'environnement système :

• XDG_GREETER_DATA_DIR
• GNOME_DESKTOP_SESSION_ID
• PYTHONDONTWRITEBYTECODE
• LESSOPEN
• XDG_SESSION_TYPE
• QT_IM_MODULE
• LOGNAME
• USER
• PROMPT_COMMAND
• HOME
• XDG_VTNR
• PATH
• PYTHONUNBUFFERED
• DISPLAY
• SSH_AGENT_PID
• LANG
• TERM
• SHELL
• XDG_SESSION_PATH
• QT_STYLE_OVERRIDE
• LANGUAGE
• SESSION_MANAGER
• SHLVL
• QT_LINUX_ACCESSIBILITY_ALWAYS_ON
• GTK_CSD
• QT_ACCESSIBILITY
• XMODIFIERS
• GIO_LAUNCHED_DESKTOP_FILE_PID
• XDG_SESSION_DESKTOP
• GIO_LAUNCHED_DESKTOP_FILE
• XDG_RUNTIME_DIR
• SSH_AUTH_SOCK
• VTE_VERSION
• GDMSESSION
• XDG_SEAT_PATH
• LESSCLOSE
• GSETTINGS_SCHEMA_DIR
• XDG_CURRENT_DESKTOP
• XDG_SESSION_ID
• DBUS_SESSION_BUS_ADDRESS
• _
• XAUTHORITY
• DESKTOP_SESSION
• XDG_CONFIG_DIRS
• GTK_MODULES
• GDM_LANG
• PANTHEON_TERMINAL_ID
• XDG_DATA_DIRS
• PWD
• PIP_PYTHON_PATH
• XDG_MENU_PREFIX
• LS_COLORS
• XDG_SEAT

Variables d'environnement spécifiques à Pipenv :

Variables d'environnement spécifiques au débogage :

• PATH : /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
• SHELL : /bin/bash
• LANG : en_US.UTF-8
• PWD : /home/mary

@MarenstainBear Dans quel Python installez-vous Pipenv ? Ou installez-vous Pipenv dans un autre Python, ou à l'intérieur d'un virtualenv ? (Pas votre projet, mais Pipenv lui-même.)

Le comportement que vous avez mentionné ci-dessous est en effet curieux, mais Pipenv fait beaucoup de détection d'environnement et est connu pour fonctionner bizarrement dans un shell mal configuré. Je ne le lirais pas trop profondément; il s'étouffe probablement avec autre chose.

@roddds resolver.py prend les dépendances qu'il veut résoudre en tant que variable d'environnement. Sans définir $PIPENV_PACKAGES avant de l'exécuter, cela résoudrait simplement une liste vide, comme il se doit, car il n'y a rien à résoudre.

Essayez d'abord de définir PIPENV_PACKAGES (le format est similaire à requirements.txt ) et voyez ce qui se passe.

+1 Je rencontre le même problème en essayant d'installer numpy sur MacOS. Vérifié Je ne vois pas ce problème lors de l'installation de boto3.

% uname -a
Darwin f45c898a1d21.ant.amazon.com 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64

@uranusjr c'est ce que j'obtiens en vérifiant PIPENV_PACKAGES avec la même valeur que celle définie dans venv_resolve_deps :

 $ PIPENV_PACKAGES=='django -i https://pypi.python.org/simple\ngraphene -i https://pypi.python.org/simple\ngraphene-django -i https://pypi.python.org/ simple\npsycopg2 -i https://pypi.python.org/simple\npsycopg2-binary -i https://pypi.python.org/simple\nipython -i https://pypi.python.org/simple\ndjango -manifold==0.1.6 -i https://pypi.python.org/simple\nscipy -i https://pypi.python.org/simple\npython-dateutil -i https://pypi.python.org /simple\ndjango-extensions -i https://pypi.python.org/simple' python /home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv /résolveur.py

 Traceback (dernier appel le plus récent) :
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", ligne 92, dans __init__
 req = EXIGENCE.parseString(requirement_string)
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1617, dans parseString
 augmenter exc
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1607, dans parseString
 loc, tokens = self._parse( instring, 0 )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1379, dans _parseNoCache
 loc, jetons = self.parseImpl( instring, preloc, doActions )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 3376, dans parseImpl
 loc, exprtokens = e._parse( instring, loc, doActions )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1379, dans _parseNoCache
 loc, jetons = self.parseImpl( instring, preloc, doActions )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 3698, dans parseImpl
 return self.expr._parse( instring, loc, doActions, callPreParse=False )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1379, dans _parseNoCache
 loc, jetons = self.parseImpl( instring, preloc, doActions )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 3359, dans parseImpl
 loc, resultlist = self.exprs[0]._parse( instring, loc, doActions, callPreParse=False )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 1383, dans _parseNoCache
 loc, jetons = self.parseImpl( instring, preloc, doActions )
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", ligne 2670, dans parseImpl
 lever ParseException (instring, loc, self.errmsg, self)
 pip9._vendor.pyparsing.ParseException : W attendu :(abcd...) (au caractère 0), (ligne :1, col :1)

 Lors du traitement de l'exception ci-dessus, une autre exception s'est produite :

 Traceback (dernier appel le plus récent) :
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", ligne 82, dans __init__
 req = Exigence(req)
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", ligne 96, dans __init__
 chaîne_exigence[e.loc:e.loc + 8]))
 pip9._vendor.packaging.requirements.InvalidRequirement : exigence non valide, erreur d'analyse à "'=django'"

 Lors du traitement de l'exception ci-dessus, une autre exception s'est produite :

 Traceback (dernier appel le plus récent) :
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", ligne 83, dans
 principale()
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", ligne 71, dans main
 clear=do_clear,
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", ligne 63, en résolution
 verbeux = verbeux,
 Fichier "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", ligne 426, dans resolve_deps
 pré,
 Fichier "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", ligne 294, dans actual_resolve_reps
 c pour c dans req.parse_requirements(t, session=pip_requests)
 Fichier "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", ligne 294, dans
 c pour c dans req.parse_requirements(t, session=pip_requests)
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", ligne 93, dans parse_requirements
 pour req dans req_iter :
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", ligne 158, dans process_line
 isolé=isolé, options=req_options, wheel_cache=wheel_cache
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", ligne 235, dans from_line
 wheel_cache=wheel_cache, contrainte=contrainte)
 Fichier "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", ligne 91, dans __init__
 "Exigence non valide : '%s'\n%s" % (req, add_msg))
 pip9.exceptions.InstallationError : Exigence non valide : '=django'
 = n'est pas un opérateur valide. Vouliez-vous dire == ?

 [[la source]]
 URL = "https://pypi.python.org/simple"
 vérifier_ssl = vrai
 nom = "pypi"

 [paquets]
 Django = "*"
 graphène = "*"
 graphène-django = "*"
 "psycopg2" = "*"
 "psycopg2-binaire" = "*"
 ipython = "*"
 django-manifold = "==0.1.6"
 scipy = "*"
 python-dateutil = "*"
 django-extensions = "*"

 [packs de développement]

 [a besoin]
 version_python = "3.6"

@roddds Vous avez un = superflu dans les environs. C'est

$ PIPENV_PACKAGES='django -i [too long, snipped]

Mais tu avais

$ PIPENV_PACKAGES=='django ...

Le deuxième = a été combiné avec django après, ce qui a entraîné l'erreur de syntaxe que vous avez vue.

Je pensais que je voyais le même problème sur une nouvelle installation d'un Mac (macOS 10.12, Homebrew Python 3), et j'ai trouvé plusieurs problèmes liés ici.

C'est une machine costaud, j'ai un bon accès à Internet - je ne sais pas pourquoi cela prend autant de temps, mais à la fin, le fichier de verrouillage a été écrit après environ trois minutes.

Pareil ici. Chaque fois que j'exécute pipenv install xxx , cela prend très longtemps (2-3 minutes) juste après l'impression Locking [packages] dependencies…

Le verrouillage prend tout simplement beaucoup de temps. En raison de la gestion des dépendances Python, nous devons télécharger chaque package et exécuter setup.py pour obtenir les dépendances nécessaires. Pour les bibliothèques comme tensorflow et numpy, vous pouvez vous retrouver avec un sdist, ce qui signifie que vous construisez à partir de la source. C'est lent. J'ai vu que ça prenait 10 minutes. Cela va plus vite si vous chauffez le cache.

Je vais fermer ce problème pour l'instant jusqu'à ce que quelqu'un puisse me montrer que son processus est bloqué ou ne fait rien. Nous envisageons des moyens d'améliorer ce processus

Serait-il possible d'afficher le package actuellement verrouillé ? Je pense que cela aiderait au moins à empêcher les gens de penser que Pipenv est suspendu.

Nous envisageons des moyens d'améliorer ce processus

Je suggérerais d'imprimer un message informant l'utilisateur que $something est en cours, ce qui pourrait « prendre quelques minutes ». À l'heure actuelle, il semble que le processus se bloque, ce qui, je suppose, amène les gens à déposer des rapports de bogue ou +1 sur ces (non-) problèmes.

@slhck Je serais intéressé de savoir pourquoi cela prend si longtemps pour commencer. Quel genre de travail pipenv doit-il faire pendant cette période ?

@anowlcalledjosh J'aime cette suggestion et je me suis probablement demandé ce qui était verrouillé moi-même. Je ne sais pas pourquoi nous n'avons jamais pensé à l'imprimer.

@Victor-Savu comme je l'ai mentionné. compiler quelque chose comme numpy ou tensorflow.

@techalchemy Mon processus, pour autant que je sache, est en fait suspendu. Je l'ai laissé cinq heures avant de le tuer. En regardant top , je n'ai vu aucune indication que quelque chose était en cours de traitement. En revanche, lorsque j'installe tensorflow dans mon virtualenv avec pip au lieu de pipenv, cela ne prend que quelques secondes.

Comme vous pouvez le voir dans cette capture de mon terminal, il a fallu 12,25 secondes à mon système pour lancer un nouveau virtualenv python3 et utiliser pip pour installer tensorflow à l'aide de la commande /usr/bin/time -v pipenv run pip install tensorflow .

Si j'exécute à la place la commande /usr/bin/time -v pipenv install tensorflow , le processus semble se bloquer indéfiniment au "Verrouillage des dépendances [packages]..." après que l'installation a déjà réussi.

Vous pouvez voir sur cette image qu'après environ 59 secondes de travail actif, le sous-processus lié à resolver.py arrête d'utiliser activement les ressources système et, pour autant que je sache, ne se terminera jamais. Lorsque j'ai pris cette capture d'écran, le processus fonctionnait depuis 16 minutes.

@MarenstainBear Pipenv génère un sous-processus à l'intérieur du virtualenv pour effectuer le verrouillage. Seriez-vous en mesure de vérifier si le sous-processus (le virtualenv python exécutant pipenv/resolver.py est en cours d'exécution lorsque Pipenv est bloqué? Je me demande s'il est bloqué à l'intérieur du résolveur, après le retour du résolveur ou pendant delegator.run …

(encore plus idéalement, vous pouvez essayer de savoir si le résolveur arrive à sa fin)

@uranusjr J'ai inséré des instructions d'écriture dans le code resolver.py et semble se bloquer quelque part dans l'appel pipenv.utils.resolve_deps à cette ligne .

En d'autres termes, resolver.py ne semble pas atteindre sa fin.

@MarenstainBear C'est bon (?) D'entendre, au moins cela signifie qu'il est débogable. Jusqu'où a-t-il réussi à pénétrer à l'intérieur resolve_deps ? C'est une fonction assez longue...

Oui et combien de temps a-t-il fonctionné ? Pour moi, cela ressemble toujours à ce que j'ai dit auparavant - résoudre le graphique de dépendance qui est lent

@techalchemy @uranusjr Je vais creuser ce qui se passe dans la fonction resolve_deps ce week-end. En attendant, voici les résultats du processus que j'ai commencé hier. Après 24 heures, il n'avait pas été résolu, et il n'utilisait vraiment aucune ressource système, donc je pense qu'il n'essayait pas de résoudre les dépendances et se contentait de se bloquer. (J'ai tué le processus afin de voir la sortie de la commande time .)

Commande sortie avec un état non nul 1
Commande chronométrée : "pipenv install tensorflow"
Temps utilisateur (secondes) : 13,63
Temps système (secondes) : 1,99
Pourcentage de CPU obtenu par cette tâche : 0 %
Temps écoulé (horloge murale) (h:mm:ss ou m:ss) : 25:45:02
Taille moyenne du texte partagé (ko) : 0
Taille moyenne des données non partagées (Ko) : 0
Taille moyenne de la pile (Ko) : 0
Taille totale moyenne (ko) : 0
Taille maximale de l'ensemble résident (ko) : 297 772
Taille moyenne de l'ensemble résident (ko) : 0
Défauts de page majeurs (nécessitant des E/S) : 0
Défauts de page mineurs (récupération d'un cadre) : 467309
Changements de contexte volontaires : 15781
Changements de contexte involontaires : 207
Échanges : 0
Entrées du système de fichiers : 0
Sorties du système de fichiers : 1654976
Messages de socket envoyés : 0
Messages de socket reçus : 0
Signaux délivrés : 0
Taille de page (octets) : 4096
Statut de sortie : 1

@techalchemy que signifie "chauffer le cache" ?

@MarenstainBear merci d'avoir fait tout ça. Votre problème est certainement un bug. D'autres dans le fil, je ne suis pas encore convaincu. Pouvez-vous installer à partir du maître et voir si nous avons résolu ce problème ?

@techalchemy que j'ai installé à partir du maître au commit 8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d (daté du samedi 31 mars 01:13:26 2018 -0400). Mon problème n'a pas été résolu. J'ai vu le même comportement ici dans la version 11.9.1 que dans la version 11.9.0.

J'ai brièvement essayé une autre façon de déboguer ce problème en utilisant strace. La commande strace pipenv install tensorflow s'est bloquée à poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) . Lorsque j'ai recherché ces descripteurs de fichiers, il n'y avait pas beaucoup d'intérêt autre que la confirmation que le système attend des E/S.

mary<strong i="10">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428937     
pipenv     8474                  mary    5r     FIFO               0,12       0t0    1428937 pipe
sh         8543                  mary    1w     FIFO               0,12       0t0    1428937 pipe
python     8544                  mary    1w     FIFO               0,12       0t0    1428937 pipe

mary<strong i="11">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428938
pipenv     8474                  mary    7r     FIFO               0,12       0t0    1428938 pipe
sh         8543                  mary    2w     FIFO               0,12       0t0    1428938 pipe
python     8544                  mary    2w     FIFO               0,12       0t0    1428938 pipe

Note latérale - Cela aiderait vraiment si nous pouvions en quelque sorte diffuser la sortie du
résolveur plutôt que de bloquer jusqu'à ce que le résolveur revienne (juste pour le rendre
plus facile à utiliser verbeux pour déboguer où le blocage se produit)
Le dimanche 1er avril 2018 à 17h21 MarenstainBear [email protected]
a écrit:

J'ai installé à partir du maître au commit 8a67a21
https://github.com/pypa/pipenv/commit/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d
(en date du samedi 31 mars 01:13:26 2018 -0400). Mon problème n'a pas été résolu. je
vu le même comportement ici dans la version 11.9.1 que je voyais dans 11.9.0.

J'ai brièvement essayé une autre façon de déboguer ce problème en utilisant strace. le
commande strace pipenv install tensorflow suspendu à poll([{fd=5,
événements=POLLIN}, {fd=7, événements=POLLIN}], 2, -1). Quand j'ai regardé ces
descripteurs de fichiers, il n'y avait pas beaucoup d'intérêt autre que
confirmation que le système attend des E/S.

marie@marvel :/proc/8471/fd

lsof -n -P | grep 1428937
pipenv 8474 marie 5r FIFO 0,12 0t0 1428937 tuyau
sh 8543 marie 1w FIFO 0,12 0t0 1428937 tuyau
python 8544 marie 1w FIFO 0,12 0t0 1428937 tuyau

marie@marvel :/proc/8471/fd

lsof -n -P | grep 1428938
pipenv 8474 marie 7r FIFO 0,12 0t0 1428938 tuyau
sh 8543 marie 2w FIFO 0,12 0t0 1428938 tuyau
python 8544 marie 2w FIFO 0,12 0t0 1428938 tuyau

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-377828171 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ABhjq95pb8cZ7BbzrjPxBq3SLeirzFehks5tkW8KgaJpZM4S0kt-
.

J'ai le même problème. Il a pendu indéfiniment dans le passé, mais la dernière fois, il s'est terminé avec une exception pour une raison quelconque. Peut-être que cela aidera. (La version est 11.9.0)

❯ pipenv install Pipfile.lock not found, creating… Locking [dev-packages] dependencies… Locking [packages] dependencies… y", line 63, in resolve verbose=verbose, File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 494, in resolve_deps list(resolver.resolve_hashes([result]).items())[0][1] File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in resolve_hashes return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in <dictcomp> return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in get_hashes for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in <setcomp> for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in _get_file_hash for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in <lambda> for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 324, in read flush_decoder = True File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 237, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') pip9._vendor.requests.packages.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443): Read timed out.

@MarenstainBear Merci d'avoir déployé tant d'efforts pour déboguer ce problème.

Après que l'installation de la version actuelle du paquet tensorflow-gpu a échoué plusieurs fois de la même manière décrite, j'ai réussi à terminer son installation en l'épinglant à la version 1.5

pipenv install tensorflow-gpu==1.5

Même si cela n'explique pas les échecs d'installation de NumPy et des autres packages, cela pourrait avoir quelque chose à voir avec le fait que depuis la version 1.6, les binaires tensorflow utilisent des instructions AVX. Dans tous les cas, la version 1.5 s'installe très rapidement et fonctionne très bien.

@paraschas J'ai essayé votre conseil, et malheureusement cela n'a pas fonctionné. Merci d'avoir suggéré quelque chose, cependant! :-)

@MarenstainBear, cela pourrait facilement être dû à la fuite de descripteurs de fichiers pipenv quelque part le long de la chaîne, puis à les attendre ... Lors de l'installation, nous bifurquons généralement un tas de sous-processus pour gérer les téléchargements simultanés, etc. Que se passe-t-il si vous utilisez pipenv install --sequential ? Merci de nous avoir supportés, n'hésitez pas à vous arrêter sur notre canal slack (le lien est https://pyslackers.com/ => inscrivez-vous et rejoignez #pipenv) si vous voulez lancer plus de choses en temps réel

@techalchemy D'après ce que je peux dire, quand il se bloque, il ne quitte jamais ce bloc try:
@ techttps://github.com/pypa/pipenv/blob/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d/pipenv/utils.py#L491 -L494

Ce code rappelle dans resolver.py, donc je vais voir ce qui se passe là-bas dans la méthode resolve_hashes() .

PS - J'ai rejoint le canal slack. Merci pour l'invitation!

Je suis confronté au même problème ici. Python 3.6.4, pipenv 11.9.0.
Il ne se bloque pas si j'installe avec --skip-lock .

@techalchemy @uranusjr

J'ai pu utiliser ipdb pour réduire considérablement mon problème ...

À partir du code pypi.py d'origine ici , si j'ajoute deux lignes, comme indiqué ci-dessous, mon pipenv n'est plus cassé .

1. La première ligne alt_session = PipSession() crée un objet PipSession vanille
2. Et la deuxième ligne self.session.adapters["https://"] = alt_session.adapters["https://"] récupère l'adaptateur https de cette session vanilla et écrase l'adaptateur https du PyPIRepository. Cela signifie qu'il passe de l'utilisation d'un pip9._vendor.cachecontrol.adapter.CacheControlAdapter à l'utilisation d'un pip9._vendor.requests.adapters.HTTPAdapter la place.

def _get_file_hash(self, location):
    h = hashlib.new(FAVORITE_HASH)
    alt_session = PipSession()
    self.session.adapters["https://"] = alt_session.adapters["https://"]
    with open_local_or_remote_file(location, self.session) as fp:
        for chunk in iter(lambda: fp.read(8096), b""):
            h.update(chunk)
    return ":".join([FAVORITE_HASH, h.hexdigest()])

Des idées sur la raison pour laquelle cela fonctionne pour moi et ce que cela signifie sur la source de mon bogue ?

Je suppose qu'il était probablement cassé parce qu'il essayait de récupérer trop de choses en même temps. Le passage à un adaptateur mis en cache réduit les requêtes dont il a besoin (car ils sont mis en cache) et le fait fonctionner. C'est presque complètement une supposition (je n'ai pas examiné les composants internes du pip et je parle uniquement sur la base de ma mémoire à la source du pip). Si cela est correct, cependant, ce serait une très bonne solution. Souhaitez-vous réduire le correctif à une demande d'extraction ?

@uranusjr C'est en fait l'inverse. Le code d'origine utilise l'adaptateur en cache - l'adaptateur en cache est celui qui ne fonctionne PAS pour moi. L'adaptateur HTTP normal fonctionne lorsque je l'utilise à la place.

@uranusjr @techalchemy Maintenant que j'y pense, je me demande s'il y a une sorte de données corrompues dans mon cache. Je vais chercher comment vider mon cache (pip?) Pour voir si cela résout le problème pour moi.

Probablement, je ne sais pas (pip interne est très difficile). Le cache de pip est à ~/.cache/pip par défaut, mais il existe peut-être d'autres caches. Honnêtement, je ne sais pas.

@uranusjr @techalchemy @jtratner

Sacré seaux, Batman ! Ça a marché!

mary<strong i="10">@marvel</strong>:~
> sudo rm ~/.cache/pip* -rf
[sudo] password for mary: 

mary<strong i="11">@marvel</strong>:~
> mktmpenv 
Using base prefix '/usr'
New python executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python3
Also creating executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/preactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/get_env_details
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-60224356c1829db) 
mary<strong i="12">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> pipenv install protobuf
Creating a Pipfile for this project…
Installing protobuf…
Collecting protobuf
  Downloading protobuf-3.5.2.post1-cp35-cp35m-manylinux1_x86_64.whl (6.4MB)
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf)
Collecting six>=1.9 (from protobuf)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf
Successfully installed protobuf-3.5.2.post1 six-1.11.0

Adding protobuf to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (735738)!
Installing dependencies from Pipfile.lock (735738)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 2/2 — 00:00:00
(tmp-60224356c1829db) 
mary<strong i="13">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> 

Voyons si cette solution fonctionne pour certaines des autres personnes signalant le même problème.
@roddds @jlhood @roveo @claytonaalves Si vous êtes toujours en mesure de reproduire pipenv suspendu indéfiniment aux dépendances "Lock... [packages]", essayez de vider votre cache pip (et pipenv?) À ~/.cache/.pip et signalez revenir sur la question de savoir si cela a résolu le problème avec la suspension de pipenv. :-)

Donc, votre invite dit @marvel mais vous citez Robin… hmm 😏

lol ... donc vider votre cache pip l'a réparé ... la vie est amusante ...

Je rencontre le même problème avec les derniers Python, pip et pipenv lors de l'installation de pendule et, malheureusement, vider le cache de pip et pipenv en exécutant `sudo rm ~/.cache/pip* -rf' ne résout pas le problème.

Donc, le problème, du moins pour moi, persiste toujours.

@paraschas pouvez-vous nous donner le pipfile et la sortie de python -m pipenv.help

Le contenu du Pipfile est :

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]
pandas = "*"
"h5py" = "*"
Keras = "*"
tensorflow-gpu = "==1.5"
sklearn = "*"
pendulum = "*"

[dev-packages]

[requires] = "3.6"

Et la sortie de python -m pipenv.help est jointe :

pipenv.help.txt

Toutes les idées sur la façon de contourner le problème, même manuellement, seront grandement appréciées.

Pouvez-vous exécuter pipenv-resolver —debug pendulum

Le voici, je ne sais pas pourquoi il échoue:

pipenv-resolver_pendulum.txt

Lors du débogage, il est utile de ne pas supprimer la commande que vous avez exécutée également, car je ne sais pas non plus pourquoi cela échoue. Vos paramètres régionaux sont-ils correctement configurés, etc. ?

J'ai copié la commande que je vois maintenant comprend un tiret au lieu de deux traits d'union.

J'ai maintenant exécuté pipenv-resolver --debug pendulum qui s'exécute correctement et produit les résultats suivants :
pipenv-resolver_pendulum.txt

Désolé pour le triage de beaucoup de choses sur mobile et cela se convertit automatiquement en tirets. Cela suggère donc un problème d'installation. Quelle version se retrouve dans votre fichier de verrouillage ? Pouvez-vous pip install cette version du pendule directement ?

Pas de soucis, je vois que vous mettez beaucoup d'efforts sur ce projet.

J'ai réussi à installer le pendule avec pipenv mais en sautant la génération du fichier de verrouillage. Après une journée et avec un nouveau démarrage, il a également généré correctement le fichier de verrouillage, et la version du pendule est "==1.5.1"

La mauvaise chose est que jusqu'à présent, il n'y a aucun moyen de reproduire ce problème, ce qui le rend difficile à résoudre, mais j'espère que quelque chose se produira.

La prochaine version devrait vous aider un peu. Je devrais l'avoir dans quelques heures.

J'ai rencontré le même problème lors de l'installation de pandas. Comme j'avais rencontré des problèmes avec les pandas et la dernière version de pip, j'ai donc décidé de rétrograder pip à 9.0.3 et le problème avec pipenv a également été résolu.
Vérifiez ce problème pour votre référence : https://github.com/pandas-dev/pandas/issues/20666

pipenv installer scrapy
bloque plus de 10 minutes

python --version
3.6.5
pip --version
10.0.1

chat

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
scrapy = "*"

[dev-packages]

[requires]
python_version = "3.6"

J'ai eu le même problème. Voici où ça pendait pour moi:

$ pipenv lock -vv
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…

$ pipenv-resolver --debug requests
DEBUG:pip9.vcs:Registered VCS backend: git
DEBUG:pip9.vcs:Registered VCS backend: hg
DEBUG:pip9.vcs:Registered VCS backend: svn
DEBUG:pip9.vcs:Registered VCS backend: bzr
DEBUG:notpip.index:2 location(s) to search for versions of requests:
DEBUG:notpip.index:* https://pypi.python.org/simple/requests/
DEBUG:notpip.index:* https://pypi.boughtbymany.com/5c0a44cd-ec93-412c-b3a9-c3dfb72c22ee/requests/
DEBUG:notpip.index:Getting page https://pypi.python.org/simple/requests/
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.python.org/simple/requests/" in the cache
DEBUG:pip9._vendor.cachecontrol.controller:Returning cached "301 Moved Permanently" response (ignoring date and etag information)
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.org/simple/requests/" in the cache
WARNING:pip9._vendor.cachecontrol.controller:Cache entry deserialization failed, entry ignored
DEBUG:pip9._vendor.urllib3.connectionpool:Starting new HTTPS connection (1): pypi.org
DEBUG:pip9._vendor.urllib3.connectionpool:https://pypi.org:443 "GET /simple/requests/ HTTP/1.1" 200 16346
DEBUG:pip9._vendor.cachecontrol.controller:Updating cache with response from "https://pypi.org/simple/requests/"
DEBUG:pip9._vendor.cachecontrol.controller:Caching due to etag

Le problème était lié au fait que pip essayait d'écrire quelque chose dans son cache. J'ai pu le résoudre en vidant mon cache pip - ce qui pour les utilisateurs de Mac est rm -rf ~/Library/Caches/pip .

Merci à tous les contributeurs de ce numéro !

Effacer le cache de pip a également fonctionné pour moi ! Merci beaucoup à @MarenstainBear @uranusjr @techalchemy @jtratner pour votre travail !

Même chose ici, pip env suspendu à Mac OS. J'ai essayé de créer un simple pipenv install flask sur un nouveau dossier uniquement à des fins de test. Il était suspendu, mais j'ai noté qu'il n'utilisait pas le répertoire de cache de pip, mais le sien :

Building wheels for collected packages: itsdangerous, MarkupSafe
  Running setup.py bdist_wheel for itsdangerous: started
  Running setup.py bdist_wheel for itsdangerous: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/2c/4a/61/5599631c1554768c6290b08c02c72d7317910374ca602ff1e5
  Running setup.py bdist_wheel for MarkupSafe: started
  Running setup.py bdist_wheel for MarkupSafe: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/33/56/20/ebe49a5c612fffe1c5a632146b16596f9e64676768661e4e46

Donc, ce qui a fonctionné pour moi était

rm -rf ~/Library/Caches/pipenv

Comportement vraiment étrange. Trouvé ce comportement après la mise à niveau de python de 3.6.3 à 3.7.0

pipenv --clear s'en chargera pour vous

Erreur : aucune option de ce type : --clear

Mettez d'abord à niveau vers la dernière version.

modifier à moins que cela ne soit pas publié et qu'il ne soit que dans le maître. Dans ce cas, attendez que je coupe une version probablement cette semaine, ou utilisez la version disponible dans le master :D je ne me souviens pas si cela a réellement fait la coupure...

@techalchemy
Il n'est certainement pas encore sorti car j'ai la dernière version 2018.7.1 et je n'ai pas non plus l'option --clear

Pour ce problème particulier, pipenv lock --clear devrait suffire.

pipenv lock --clear fonctionne. Merci!

ne fonctionne toujours pas pour moi pour pipenv lock --clear

macOS High Sierra 10.13.6
Python : Python 3.6.4
pipenv : version 2018.7.1

J'espère que ce Locking [packages] dependencies... sera résolu pour toujours dès que possible

@crifan J'ai trouvé qu'il y avait un bogue qui empêchait pipenv lock --clear de fonctionner (https://github.com/pypa/pipenv/issues/2628).

Essayez de vider manuellement vos caches - j'utilise rm -r ~/Library/Caches/pip* .

Se passe dans ce Dockerfile basé sur Linux alpin (enfant de this ):

FROM frolvlad/alpine-python3

RUN pip install pipenv

COPY ./app /app
COPY Pipfile /app/
WORKDIR /app

RUN pipenv install

Avec ce Pipfile :

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[dev-packages]

[packages]
numpy = "*"
pandas = "*"
tensorflow = "*"
flask = "*"

[requires]
python_version = "3.6"

~/devel/dopper:fixes: pipenv lock --clear --verbose
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

pend pour toujours.

Pipfile :

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
proto = {editable = true, path = "."}
halt = {editable = true, path = "/home/carlos/devel/halt"}
gcd = {editable = true, path = "/home/carlos/devel/gcd"}

[dev-packages]

[requires]
python_version = "3.6"

Les fichiers de verrouillage qui ne contiennent que des éléments qui se trouvent sur votre ordinateur local sont tout aussi inutiles que de ne fournir aucune information. À moins que vous n'offriez de nouvelles informations de débogage ou une nouvelle chose que nous pouvons prendre et reproduire, veuillez faire attention au bruit du suivi des problèmes.

Ce sont de simples projets de dépendance que je peux facilement installer manuellement en exécutant pip install -e . sur chacun d'eux, mais l'exécution pipenv install -e . sur le projet principal se bloque indéfiniment, j'ai donc découvert ce problème et essayé pipenv lock --clear qui se bloque également. Je comprends que vous ne pouvez pas faire grand-chose sans plus d'informations, mais au moins c'est la preuve que les choses qui fonctionnent bien à l'ancienne sont suspendues avec pipenv et que la solution proposée ne fonctionne pas partout. Désolé, je ne peux pas fournir plus d'informations. Peut-être que si le mode --verbose était effectivement verbeux ici.

Peut-être que ceci pourrait éclairer:

~/devel/dopper:fixes: pipenv --rm
Removing virtualenv (/home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s)...
~/devel/dopper:fixes: rm -rf Pipfile 
~/devel/dopper:fixes: pipenv --three
Creating a virtualenv for this project...
Pipfile: /home/carlos/devel/dopper/Pipfile
Using /usr/bin/python3 (3.6.6) to create virtualenv...
⠋Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python3
Also creating executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python
Installing setuptools, pip, wheel...done.
Setting project for dopper-0v9QQl0s to /home/carlos/devel/dopper

Virtualenv location: /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s
Creating a Pipfile for this project...
~/devel/dopper:fixes: pipenv install numpy
Installing numpy...
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Attendre pour toujours...

Supposons que ce soit un problème de réseau, maintenant pourquoi cela fonctionne alors ? :

~:: pip install --force --upgrade --user numpy
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl (13.9MB)
    100% |████████████████████████████████| 13.9MB 386kB/s 
Installing collected packages: numpy
  Found existing installation: numpy 1.15.0
    Uninstalling numpy-1.15.0:
      Successfully uninstalled numpy-1.15.0
Successfully installed numpy-1.15.0

Après de nombreuses tentatives (installation des dépendances une par une, évitement des dépendances locales, évitement des dépendances modifiables, installation avec verrouillage puis verrouillage, etc.), je n'ai trouvé aucun modèle. Parfois, cela fonctionne dans un laps de temps raisonnable, parfois il s'interrompt après quelques minutes avec une erreur de délai d'attente, parfois il se bloque "pour toujours" (dont la définition dépend de ma patience décroissante). Je suppose que mon problème est lié aux nombreux problèmes signalant une variante de "le verrouillage est trop lent".

Encore une fois, arrêtez de faire des suppositions aléatoires et de publier des extraits aléatoires de votre sortie. Si vous souhaitez obtenir de l'aide pour un problème spécifique, remplissez un problème avec l'intégralité du modèle de problème. Nous n'allons pas nous lancer dans une chasse à l'oie sauvage avec qui que ce soit dans ce numéro alors qu'ils publient de manière sélective une sortie qui n'est pour la plupart pas liée à pipenv. Nous avons vu à quoi ressemble l'écran lorsqu'il se bloque. Nous coller ça n'est pas utile.

Ok, si vous pensez que ne pas installer numpy dans un environnement propre est un
problème aléatoire, je sais que je tente ma chance en utilisant pipenv, merci pour
la tête haute et je vais fermer ma gueule.

Le mercredi 25 juillet 2018 à 18h27, Dan Ryan [email protected] a écrit :

Encore une fois, s'il vous plaît, arrêtez de faire des suppositions au hasard et de publier des extraits aléatoires de
votre sortie. Si vous souhaitez obtenir de l'aide pour un problème spécifique, remplissez un problème
avec l'ensemble du modèle de problème. Nous n'allons pas à la poursuite de l'oie sauvage avec
n'importe qui dans ce numéro alors qu'ils publient de manière sélective une sortie qui est principalement
sans rapport avec pipenv. Nous avons vu à quoi ressemble l'écran lorsqu'il se bloque.
Nous coller ça n'est pas utile.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-407901419 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACtq-WfYHCgtRnbIu_yljQV7m0JvwxA7ks5uKOKqgaJpZM4S0kt-
.

@memeplex il ne s'agit pas d'un problème aléatoire, il s'agit de la sortie qui n'est pas utile pour le dépannage. En aucun cas je n'ai qualifié votre problème de aléatoire - je vous ai dit spécifiquement ce que vous pouvez faire si vous souhaitez avoir une conversation productive sur le problème auquel vous êtes confronté, car il est impossible de dépanner ou de diagnostiquer un système avec des fragments sélectionnés de terminal sortie qui ne comprend que des messages que nous avons écrits nous-mêmes et qui ne contiennent en fait aucune erreur ni aucun moyen pour nous de le reproduire.

Jusqu'à présent, nous savons:

1. Rien sur votre environnement
2. Rien sur les circonstances supplémentaires entourant votre système
3. L'affirmation exagérée selon laquelle vous avez "attendu pour toujours", mais sans aucune information supplémentaire sur la question de savoir si le processus faisait quelque chose, si un environnement existait avec quoi que ce soit, quelle version de pipenv vous utilisez, si cela se produit avec des choses autres que numpy, comment vous avez installé python, à quoi ressemble votre matériel, à quoi ressemble votre configuration système, je pourrais continuer.

Nous trions un nombre considérable de problèmes, c'est pourquoi nous utilisons des modèles de problèmes pour nous aider à rassembler rapidement ces informations afin d'évaluer ce qui pourrait se produire. Lorsque les gens collent simplement "[verrouiller]..." et nous disent "cela prend une éternité", nous compatissons pour vous, mais c'est en quelque sorte une première indication que vous n'êtes pas réellement là pour être productif. J'essaie de donner le bénéfice du doute et d'exhorter les gens à signaler un problème avec le modèle de problème et un cas de test reproductible, mais si vous ne pouvez pas le faire, je ne peux que supposer que votre intention n'était pas réellement de dépanner et que vous ne faites que voulait être négatif. Ce n'est pas vraiment le bienvenu sur le suivi des problèmes, il y a beaucoup d'autres endroits où vous pouvez le faire.

Ce tracker est utilisé pour identifier et résoudre les problèmes avec la base de code, pas pour empiler chaque fois que vous voyez quelque chose que vous avez vécu. La règle est essentiellement que si vous ne pouvez pas ou ne voulez pas contribuer quoi que ce soit au-delà de reformuler quelque chose et de nous dire que nous devons le réparer immédiatement, vous devriez probablement vous abstenir de publier. Nous sommes bénévoles et nous le faisons pendant notre temps libre ; si vous venez au tracker, vous nous demandez directement de consacrer notre temps à vous. Nous sommes généralement en mesure de le faire, mais nous vous demandons en retour de suivre notre processus pour nous aider à trier efficacement.

Je ne veux vraiment pas continuer cette discussion à cause des autres personnes abonnées au fil, je répondrai à celle-ci et ensuite vous aurez le dernier mot si vous le désirez. J'ai posté des preuves anecdotiques, j'ai rapidement reconnu que ce n'était pas plus que cela et j'ai essayé d'éliminer les aspects les plus contingents en installant les dépendances locales par d'autres moyens et en vérifiant qu'il n'y avait pas de problèmes avec elles et enfin en supprimant complètement toutes les dépendances, en démarrant un env à partir de zéro et en installant juste numpy. Ces étapes (création d'un env et installation de numpy) sont reproductibles, je suis sincèrement désolé de ne pas pouvoir vous fournir d'informations plus utiles car je suis moi-même incapable de trouver un modèle, comme je l'ai remarqué lors de la liste de mes tentatives (et je ne peux pas non plus joindre un iso de toute ma configuration). Ainsi, à la fin, j'ai suggéré une relation avec un certain nombre de problèmes, trop similaires, qui ont été signalés et fermés, en reconnaissant que ma première impression avait été erronée. Je comprends que la reproductibilité est meilleure, mais je ne peux même pas publier une sortie détaillée car la commande montre simplement cette sortie minimale que j'ai publiée (de manière sélective ou aléatoire ou autre). Au début, je pensais que mon problème pouvait être lié à ce problème et après mes tentatives infructueuses pour trouver un modèle, je me sens maintenant plus enclin à croire que c'est du côté "le verrouillage est trop lent". La raison pour laquelle je n'ai pas créé de nouveau problème est qu'il y en a beaucoup qui sont fermés pour la même raison pour laquelle vous auriez certainement fermé le mien si je devais le publier. Maintenant, je pense que c'est un problème important, je ne parviens pas à installer de manière cohérente un package populaire dans une configuration principalement standard, il ne s'agit pas de la police serpent emoji qui ne fonctionne pas sur mon nouvel émulateur de terminal hipster et, même si je comprends votre position , je ne peux m'empêcher de penser que vous avez été un peu trop dur. Cela dit, j'apprécie vraiment votre explication détaillée après mon dernier commentaire de mauvaise humeur. Au fait, l'affirmation selon laquelle j'ai `` attendu pour toujours '', en plus d'être une figure de style, a en effet été atténuée par moi, ironique, en définissant pour toujours comme la limite de ma patience, mais j'ai fourni des informations indiquant qu'il était supérieur à plusieurs minutes ; puisqu'il s'agit ici de quelque chose qui aurait dû prendre tout au plus quelques secondes, la seule pertinence de mon imprécision est que vous l'avez interprétée comme un symptôme précoce de mes mauvaises intentions qui n'étaient pas là au départ. Mes excuses à tous les autres ici, du moins à tous ceux qui ont eu la patience de lire jusqu'à présent.

Si vous pensez que vous avez quelque chose de nouveau à ajouter sur ce sujet, veuillez créer un nouveau problème et remplir entièrement le modèle de problème. Nous sommes conscients des problèmes et de leurs diverses manifestations, et nous avons plusieurs correctifs en cours