Pipenv: La mise à jour du verrou est très lente

Nous sommes conscients et avons de nombreux problèmes pour suivre ce sujet. Voir #1785 #1886 #1891 et PR #1896

npm et fil ont l'avantage de ne pas avoir à télécharger et à exécuter entièrement chaque package potentiel pour déterminer leur graphique de dépendance, car les dépendances sont spécifiées en texte clair. Les dépendances Python nous obligent à télécharger et à exécuter entièrement les fichiers d'installation de chaque package à résoudre et à calculer. C'est juste la réalité, c'est un peu lent. Si vous ne pouvez pas attendre 2 minutes ou si vous pensez que cela ne vaut pas le compromis, vous pouvez toujours passer --skip-lock .

Fermeture à suivre dans les autres numéros.

Idem ici, je l'essaye maintenant et l'installation de Django est déjà à 10 minutes et va

semble que si vous essayez d'en installer quelques-uns à la fois, c'est lent, mais si vous en faites un à la fois, cela fonctionne un peu plus vite

Si vous pouvez fournir un Pipfile qui reproduit le comportement lent, ce serait utile - merci

Les dépendances Python nous obligent à télécharger et à exécuter entièrement les fichiers d'installation de chaque package pour résoudre et calculer

Est-ce toujours le cas lorsque le package a son propre Pipfile.lock , ou pipenv l'utilisera-t-il lorsque cela sera possible pour déterminer les dépendances ?

pipenv l'utilisera-t-il lorsque cela sera possible pour déterminer les dépendances ?

Non. Pipenv est un outil de résolution de dépendance des applications. Lorsqu'une dépendance est utilisée comme package Python par une autre application, ce n'est plus une application. Ses dépendances sont déterminées par setup.py (ou setup.cfg ou tout ce que vous utilisez pour télécharger sur PyPI). Le chargement de dépendances à partir d'un fichier de verrouillage est une voie sûre vers l'enfer des dépendances, nous ne le ferons probablement jamais.

C'est toujours super lent

@iddan Merci pour le rappel, Capitaine Obvious !

Désolé, en tant que mainteneur d'OSS, je sais que des problèmes peuvent parfois être ignorés en raison de l'âge. Je voulais juste dire que même la question a fait l'objet d'une discussion, elle est toujours d'actualité

La note --skip-lock ci-dessus est merveilleuse. Cela devrait être une option plus accessible ou plus médiatisée. Pouvons-nous le définir par défaut quelque part?

@techalchemy et si ça

La note --skip-lock ci-dessus est merveilleuse. Cela devrait être une option plus accessible ou plus médiatisée. Pouvons-nous le définir par défaut quelque part?

Pour autant que je sache, l'énorme avantage de pipenv est que les dépendances d'assurance fonctionneront bien ensemble - pas seulement pour vous, mais pour toute personne qui s'occupera plus tard de votre code. Le produit de cette assurance, le fichier de verrouillage, prend absolument plus de temps que quiconque s'y attend ou ne le souhaite, _y compris les développeurs_ — voir #2200.

Cependant, je pense que vous pouvez également comprendre l'opportunité qu'a pipenv de guider les développeurs bien intentionnés de la communauté Python dans son ensemble vers un flux de travail imposant moins de prise de tête aux futurs contributeurs - qui n'auraient peut-être été que des visiteurs s'ils avaient abandonné pendant le " comprendre comment configurer l'étape de l'environnement de développement ; et moins de mains levées par les futurs mainteneurs - qui n'auraient peut-être été conduits que par des auteurs de relations publiques s'ils avaient abandonné pendant la phase de "sérieusement fouillis avec des internes de projet profonds".

Si --skip-lock devenait un indicateur permanent dans un Pipfile ou un paramètre dans une configuration pipenv, la perception de pipenv glisserait lentement vers un "meilleur pip", et juste un autre tremplin s'estompant à l'horizon alors que la communauté atterrissait finalement sur un successeur spirituel moins compromettant.

Mieux vaut le laisser disponible uniquement en tant que var env, ou une autre méthode dont l'application repose carrément sur le territoire de _"votre configuration locale spécifique à l'utilisateur, votre faute"_, permettant à pipenv de surmonter la phase de lenteur de génération de fichier de verrouillage sans abandonner le changement culturel vraiment bénéfique vers _l'explicite plutôt que l'implicite_ dans la gestion des paquets.

La bibliothèque standard incroyablement vaste de Python est un atout énorme, dont l'histoire a connu de nombreuses époques d'une cohérence imposante. Le fait que la plupart des packages standard fonctionnent bien ensemble est un exploit énorme impliquant une réflexion sur de nombreuses années par de nombreuses personnes. Un jour, cette capacité de jeu s'étendra à la plupart des projets Python rencontrés sur le Web - loin, loin de la stdlib, et avec beaucoup, beaucoup moins de PEP requis (_et beaucoup, beaucoup moins de BDFL qui se libèrent par frustration_). L'impact d'une telle façon unilatérale de beurre expérience est difficile à mesurer, mais les rebuts de certaines langues actuelles de compromettre l' intégrité conceptuelle pour la commodité immédiate ... et oh, les endroits qu'ils vont Go .

Donc _oui_, générer le fichier de verrouillage est lent, et _oui_, c'est frustrant quand vous ne vouliez que pip install --save . Mais c'est seulement parce que nous avons balayé un éléphant dans le placard pendant des années - en croyant que nous n'avions pas un enchevêtrement d'attentes et d'intentions provenant de dépendances externes, car _"il s'est bien installé sur ma machine"_.

La génération du fichier de verrouillage est lente _uniquement_ parce qu'elle rend explicite ce que nous tenons tous pour acquis. Mais _parce que_ ça fait mal , on va ajuster les choses pour que ça ne le fasse pas. Nous nous sommes cassés le bras parce que nous nous sommes poussés à faire des choses auxquelles nous croyions. Bien sûr, nous pouvons éviter la douleur en ne réutilisant plus ce bras - ou nous pouvons le mettre dans un plâtre pendant qu'il guérit.

Je serais la dernière personne à vous dire de ne pas rendre pipenv pratique pour vous-même aujourd'hui (sinon je serais un développeur de merde - _bien que le jury soit toujours absent_), mais je vous implore de voir la frustration de la génération de fichiers de verrouillage comme un douleur tandis que la communauté Python se développe en un corps fort et sain avec des membres plus fonctionnels qu'on ne s'y attendait vraiment lors du retrait d'un plâtre. Nous avons atteint Python 3. Passons à la gestion des dépendances dans la stdlib.

Cela a pris 38 minutes sur ma machine pour créer le fichier de verrouillage. Exécution de Windows 10 et utilisation de Python 3.7

Seuls le numpy et l'oreiller étaient déjà installés et il a fallu <1 seconde pour installer numba et 25 minutes pour le verrouiller. Pipenv compile-t-il de force toutes les bibliothèques verrouillées ou comment cela fonctionne-t-il ?

Pour info, le verrouillage de saut persistant attend simplement que quelqu'un bascule le commutateur pour auto_envvar_prefix qui est un paramètre de clic. Je me suis concentré à 100% sur les fonctionnalités de base, donc je n'ai pas encore eu l'occasion de regarder cela, mais je soupçonne que ce n'est pas si difficile

TLDR ; Invocation typique de pipenv install : Heure : 144,82 réel 33,68 utilisateur 5,77 sys. Avec --skip-lock : Temps : 4.54 réel 5.33 utilisateur 0.87 sys.

L'installation de Pandas-datareader échoue à la première tentative, peut-être à cause d' lock blocage de

Utilisation de la version 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Contenu de requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Invocation typique de pipenv install . Exécution chronométrée en utilisant time (BSD).

Résultats : 144.82 réel 33.68 utilisateur 5.77 sys

$ time pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Pipfile.lock (0fdb67) out of date, updating to (a65489)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (0fdb67)!
Installing dependencies from Pipfile.lock (0fdb67)…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 15/15 — 00:00:04
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
      144.82 real        33.68 user         5.77 sys

Invocation avec --skip-lock

Résultats : 4.54 réel 5.33 utilisateur 0.87 sys

$ time pipenv install -r requirements.txt --skip-lock
Requirements file provided! Importing into Pipfile…
Installing dependencies from Pipfile…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
        4.54 real         5.33 user         0.87 sys

Je pense que https://github.com/pandas-dev/pandas/ peut être un problème ? C'est un point commun avec le temps pour moi aussi.

Bien que pytest puisse aussi être un problème :\

Il ne se termine même pas sur ma machine :

Installing pandas…
Adding pandas to Pipfile's [packages]…
Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 109, in expect_loop
    return self.timeout()
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x00000292ADCCCDD8>
searcher: searcher_re:
    0: re.compile('\n')

@black-snow Je recommanderais de l'essayer dans un autre shell. Sans plonger trop profondément dans les choses, il semble que pexpect (une bibliothèque pour l'interfaçage par programmation avec des programmes CLI interactifs) soit utilisé pour détecter le shell à partir duquel pipenv est exécuté, et cela pourrait être en train de caler. L'attente semble un peu exagérée pour une telle chose, mais je ne suis pas au courant de tout le contexte.

@theY4Kman merci pour les conseils. pipenv fonctionne bien sur un autre pc avec la même version ubuntu et bash ...

Lisez ceci en attendant que pipfile se verrouille... :) Ce serait bien s'il y avait une solution.

Il semble que nous ayons besoin d'une sorte d'API pour analyser et mettre en cache les deps de packages Python et les distribuer dans un format convivial. Nous n'aurons donc plus besoin de télécharger des packages entiers et de les analyser.

Je crois que bundler et ruby ​​gems maintient et utilise quelque chose comme ça.

Java a également des fichiers POM (XML) qui contiennent des dépendances de package et d'autres informations sur le package. Ils sont téléchargés séparément des JAR compilés.

Chaque nouveau gestionnaire de paquets a des méta-fichiers distincts (npm/yarn, composer, gradle/maven, cargo, ruby ​​gems/bundler, ...).

problème connexe :
https://github.com/pypa/warehouse/issues/474

Vous pouvez obtenir des informations de dépendance à partir de PyPi sans télécharger l'intégralité du bundle (voir PEP 566, qui a remplacé PEP 426).

package_name = 'Django'
PYPI_API_URL = 'https://pypi.python.org/pypi/{package_name}/json'
package_details_url = PYPI_API_URL.format(package_name=package_name)
response = requests.get(package_details_url)
data = json.loads(response.content)
data['info'].get('requires_dist')
data['info'].get('requires')
data['info'].get('setup_requires')
data['info'].get('test_requires')
data['info'].get('install_requires')

@techalchemy avez-vous vu le commentaire ci-dessus ?

Cela se produit assez régulièrement, essentiellement des pipenv qui s'éloignent de la ville tout en "verrouillant" quelque chose : pourquoi ce problème est-il fermé ?

Comprenez que le --skip-lock est la voie à suivre, mais il n'est pas clair du tout pourquoi « l'installation » prend quelques secondes et « verrouiller » prend une éternité : ce serait formidable si au moins la commande de verrouillage émettait des progrès /mettre à jour les journaux : dans l'état actuel des choses, il n'est même pas clair s'il vient de rester bloqué dans une sorte de while True pour toujours...

J'aimerais au moins savoir si c'est moi qui fais quelque chose de mal, ou juste une "fonctionnalité" de pipenv.

Dans notre projet, pipenv lock est tellement tellement lent. Cela a certainement eu un impact sur notre utilisation normale. L'ajout d'un nouveau package devient une vraie douleur pour nous maintenant. Existe-t-il un moyen de déboguer ce comportement ?

J'essaie d'installer PyTorch et il a fallu 20 minutes pour se verrouiller, puis il génère l'erreur suivante

Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1992, in do_install
[pipenv.exceptions.InstallError]:       skip_lock=skip_lock,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Collecting pytorch==1.0.2 (from -r /tmp/pipenv-pb00kf8t-requirements/pipenv-vae35p2d-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ee/67/f403d4ae6e9cd74b546ee88cccdb29b8415a9c1b3d80aebeb20c9ea91d96/pytorch-1.0.2.tar.gz', 'Building wheels for collected packages: pytorch', '  Building wheel for pytorch (setup.py): started', "  Building wheel for pytorch (setup.py): finished with status 'error'", '  Running setup.py clean for pytorch', 'Failed to build pytorch', 'Installing collected packages: pytorch', '  Running setup.py install for pytorch: started', "    Running setup.py install for pytorch: finished with status 'error'"]
[pipenv.exceptions.InstallError]: ['ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' bdist_wheel -d /tmp/pip-wheel-f_h8w1pz --python-tag cp36:', '  ERROR: Traceback (most recent call last):', '    File "<string>", line 1, in <module>', '    File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 15, in <module>', '      raise Exception(message)', '  Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '  ----------------------------------------', '  ERROR: Failed building wheel for pytorch', '    ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch:', '    ERROR: Traceback (most recent call last):', '      File "<string>", line 1, in <module>', '      File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 11, in <module>', '        raise Exception(message)', '    Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '    ----------------------------------------', 'ERROR: Command "/home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch" failed with error code 1 in /tmp/pip-install-hix3yz6v/pytorch/']
ERROR: ERROR: Package installation failed...

L'erreur est unreadle, aucune idée de ce qui s'est mal passé. L'installation avec pip dans l'environnement fonctionne très bien ! C'est vraiment un spectacle. Retour au fichier requirements.txt...

Voici la solution de contournement que j'utilise pour le moment :

export PIPENV_SKIP_LOCK=true

Ensuite, pipenv install foo ne se verrouillera pas et vous pourrez verrouiller manuellement lorsque vous aurez le temps en exécutant pipenv lock .

@awhillas Je suis sûr que la dernière ligne dit tout ce dont vous avez besoin :

Vous avez essayé d'installer "pytorch". Le paquet nommé pour PyTorch est "torch"

Le verrouillage des dépendances est important, donc je ne pense pas que "ignorer le verrouillage" soit une solution durable. En même temps, je n'achète tout simplement pas que les "dépendances de verrouillage" (quoi que cela puisse impliquer sous le capot) soit optimisée au maximum comme c'est le cas actuellement et nécessite de nombreuses minutes ou heures pour se terminer. En effet, mon verrou pipenv a fonctionné pendant plusieurs minutes sur un Pipfile qui a 5 dépendances risibles avant d'échouer - pile attachée en bas - et pendant ce temps n'a utilisé que 10 à 15% du processeur disponible et une petite gorgée de mémoire.

Pouvons-nous au moins faire un effort de groupe pour profiler et déterminer les goulots d'étranglement ? J'ai le sentiment qu'il n'y a que des fruits stupides à portée de main qui n'attendent que de prendre ce processus dans un temps d'exécution raisonnable.

pipenv version 2018.11.26

Pour Pipfile :

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

[packages]

[dev-packages]
keras = "*"
tensorflow = "~=1.13"
setuptools = "*"
wheel = "*"
twine = "*"

[requires]
python_version = ">=3.6"

Pipfile.lock (63b275) out of date, updating to (5e165c)…
Locking [dev-packages] dependencies…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 109, in expect_loop
    return self.timeout()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.26', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/cli/command.py", line 254, in install
    editable_packages=state.installstate.editables,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1992, in do_install
    skip_lock=skip_lock,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1221, in do_init
    pypi_mirror=pypi_mirror,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1068, in do_lock
    lockfile=lockfile
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps
    c = resolve(cmd, sp)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 517, in resolve
    result = c.expect(u"\n", timeout=environments.PIPENV_INSTALL_TIMEOUT)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/delegator.py", line 215, in expect
    self.subprocess.expect(pattern=pattern, timeout=timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 341, in expect
    timeout, searchwindowsize, async_)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 369, in expect_list
    return exp.expect_loop(timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 119, in expect_loop
    return self.timeout(e)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

En complément du commentaire précédent, l'exécution de pip lock séparément a pris un temps raisonnable, environ 15 secondes, après la première exécution de pip install --skip-lock . Alors peut-être que l'invocation post-installation du verrou est obsolète ou autrement défectueuse. :)

Pour info, j'ai trouvé que tensorflow est le coupable du verrouillage lent/de temporisation, si cela aide à profiler pipenv! (Considérez toujours cela comme un problème pipenv...)

Tensorflow est l'un des nombreux packages qui peuvent faire de pipenv un outil inutile. J'aime la suggestion du profilage de groupe, cependant. Je pense que c'est une excellente idée pour commencer à s'attaquer à ce problème. Juste pour réitérer, PEP 566 a permis d'énumérer la dépendance (via pypi) sans charger l'intégralité de la source, ce qui peut être utile : https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz d' après ce que je vois, le téléchargement de tous les packages des dépendances est l'endroit où l'on passe le plus de temps. Cela a également été confirmé auparavant.

Comment vérifier cela :

• Essayez de créer un nouveau Pipfile et d'y installer scipy (par exemple) avec le verrouillage activé
• Attendez la fin du verrouillage. (Prend environ 5 minutes sur ma machine)
• supprimer Pipfile.lock
• exécuter pipenv lock - le verrouillage maintenant prendra très peu de temps (6 secondes sur ma machine), car tous les packages sont déjà téléchargés et conservés dans le cache Pipenv qui se trouve normalement dans ~/.cache/pipenv

Voici le Dockerfile que j'ai utilisé pour tester ceci :

FROM python:3.6
ENV WORKDIR=/work/
WORKDIR /work/
RUN python3 -m pip install --upgrade pip
RUN python3 -m pip install pipenv
RUN PIPENV_SKIP_LOCK=true pipenv install scipy
RUN date
RUN pipenv lock
RUN date
RUN rm Pipfile.lock
RUN pipenv lock
RUN date

@shtratos Oui, cela a du sens et d'autres l'ont suggéré dans ce fil de discussion. Le téléchargement et l'analyse des dépendances sont coûteux. Certaines de ces étapes semblent pouvoir être éliminées en tirant parti de l'API de dépendance pypi.

Pour certaines bibliothèques, cela ne fonctionnera probablement pas, en raison d'une mauvaise qualité et de mauvaises pratiques (ne pas utiliser setup.py ou requirements.txt). Mais étant donné que certains des principaux délinquants semblent être des bibliothèques très populaires (tensorflow, numpy), la mise en œuvre de cela avec un recours au processus super lent pourrait être une bonne voie à suivre.

Pouvez-vous m'indiquer où trouver ce code? Je pourrais essayer de le paralléliser dans une fourchette.

Je pense que https://github.com/pandas-dev/pandas/ peut être un problème ? C'est un point commun avec le temps pour moi aussi.

Bien que pytest puisse aussi être un problème :\

Je ne pense pas, ça marche bien sur ma machine, le problème semble être plus général que ça

Dans mon cas, le problème semble être pylint. Il se bloque toujours lors du verrouillage lors de l'exécution simple de pipenv install pylint voir https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

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

Exemple de travail minimal

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...

Nous sommes conscients et avons de nombreux problèmes pour suivre ce sujet. Voir #1785 #1886 #1891 et PR #1896

npm et fil ont l'avantage de ne pas avoir à télécharger et à exécuter entièrement chaque package potentiel pour déterminer leur graphique de dépendance, car les dépendances sont spécifiées en texte clair. Les dépendances Python nous obligent à télécharger et à exécuter entièrement les fichiers d'installation de chaque package à résoudre et à calculer. C'est juste la réalité, c'est un peu lent. Si vous ne pouvez pas attendre 2 minutes ou si vous pensez que cela ne vaut pas le compromis, vous pouvez toujours passer --skip-lock .

Fermeture à suivre dans les autres numéros.

3 des 4 autres problèmes sont maintenant fermés et le dernier n'a vu aucune activité depuis 2018. Ce problème persiste, alors peut-être que sa réouverture serait une bonne idée ?

Les dépendances Python nous obligent à télécharger et à exécuter entièrement les fichiers d'installation de chaque package pour résoudre et calculer

Je ne pense pas que ce soit encore vrai pour les roues, qui devraient être la majorité des packages maintenant ?

Je sais que je dois au moins construire la roue pour dlib à chaque fois, ce qui est horrible.

Le processus de résolution des dépendances doit être mis en cache quelque part sur une base par version de package, même s'il nécessite une autre recherche à distance sur le client à chaque fois pour obtenir l'arborescence (cela ne devrait pas, vous pouvez simplement le mettre en cache localement aussi après le fait ). Par exemple, les dépôts de packages pourraient facilement stocker des arbres dep résolus. Le coup réseau supplémentaire pour l'arbre dep résolu mis en cache serait toujours plus rapide que le téléchargement d'un package entier et le calcul.

FWIW J'ai supprimé pipenv de tous mes projets (c'est la raison principale, il y en a d'autres).

virtualenv + pip (avec requirements.txt ) fonctionnent maintenant assez bien, même pour les déploiements Prod ; et de toute façon, on déploie aujourd'hui un conteneur complet ; après m'être vraiment lancé dans pipenv, je n'en vois plus l'intérêt.

Veuillez rouvrir ce problème.
Sinon pipenv ne sera jamais l'outil de packaging de référence