Pip: assertion lors de l'utilisation de --no-cache-dir dans 19.0

Même chose avec:
Python v3.6.8
pip version 18.1
sur
Ubuntu:latest image.

@snstanton quelle image de base utilisez-vous? Je vois également un problème similaire sur pip v18.1

J'ai exactement le même problème.
de mon côté, il semble que peu importe le paquet / la distribution que j'essaie d'installer

Je vois cela même sans --no-cache-dir ensemble. Cela se produit pour tous les packages que j'essaie d'installer, même s'ils sont déjà installés.

• version de pip: 19.0
• Version Python: 3.6.0
• Système d'exploitation: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-x86_64 générique)

Je dois noter que dans mon cas, je le vois en exécutant pip avec une combinaison de sudo -H et bash -l -c .

$ sudo -H bash -l -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Looking in indexes: https://pypi.org/simple, http://pypi.lan.cogtree.com/cogtree/simple/
Collecting hypothesis
  Downloading http://pypi.lan.cogtree.com/cogtree/simple/hypothesis/hypothesis-4.1.0-py3-none-any.whl (238kB)
    100% |████████████████████████████████| 245kB 120.5MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Exception:
Traceback (most recent call last):
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

Exécuter les mêmes commandes sans -l sur mon bash -c , ou sans bash -l -c impliqué du tout, tout fonctionne bien.

$ sudo -H bash -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Collecting hypothesis
  Downloading https://files.pythonhosted.org/packages/89/7b/d6206dcde963139daa03a1d85b0c3428cb3ebf2ae8de3244b14a63e22680/hypothesis-4.1.0.tar.gz (180kB)
    100% |████████████████████████████████| 184kB 33.7MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Building wheels for collected packages: hypothesis
  Building wheel for hypothesis (setup.py) ... done
  Stored in directory: /root/.cache/pip/wheels/10/12/eb/4ab734432e8466d545c8501f531458845b45e8c4427d5367f9
Successfully built hypothesis
Installing collected packages: hypothesis
Successfully installed hypothesis-4.1.0

Fait fascinant, si j'exécute la même commande sans sudo ou bash impliqués, cela échoue toujours avec la même erreur, il semble donc que ce soit un problème d'autorisations étrange peut-être.

Une autre solution de contournement pour certaines situations

Pour les personnes qui rencontrent ce bogue parce que virtualenv installe automatiquement la dernière version de pip, vous pouvez le contourner en donnant à virtualenv l'option --no-download , ou en définissant VIRTUALENV_NO_DOWNLOAD=1 .

Mais sachez que cela peut vous donner une très ancienne version de pip, en fonction de la dernière mise à niveau de virtualenv.

Cela fonctionne également avec tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

pour ce que ça vaut: il échoue également avec la même erreur si le package est déjà installé:

gregory.starck<strong i="6">@canon</strong>:~/tmp$ ./venv/bin/pip install --no-cache-dir six ; echo $?
Looking in indexes: http://pypi:3141/root/ax/+simple/
Requirement already satisfied: six in ./venv/lib/python3.6/site-packages (1.12.0)
Exception:
Traceback (most recent call last):
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
2
gregory.starck<strong i="7">@canon</strong>:~/tmp$

Ran dans le même problème. J'ai fini par épingler la version pip comme correctif pour le moment.

pip install --upgrade pip==18.1

Le problème est lié à l'échec de l'assertion, donc la définition de env PYTHONOPTIMIZE = 1 (ou avec le paramètre -O) fait disparaître cette erreur.
Je viens de le tester.
Cette solution de contournement fonctionne car python optimise le code en supprimant toutes les assertions comme l'une des choses.
N'allez pas pour = 2 (ou -OO), car cela supprime les docstrings et d'autres traces apparaîtront - certains codes veulent les utiliser.

Il semble que quelqu'un savait que cela pourrait finir par être un problème ( source ):

        # TODO: This check fails if --no-cache-dir is set. And yet we
        #       might be able to build into the ephemeral cache, surely?
        building_is_possible = self._wheel_dir or (
            autobuilding and self.wheel_cache.cache_dir
        )
        assert building_is_possible

https://github.com/pypa/pip/pull/5884 ressemble à un changement lié qui aurait pu en être la cause?

On dirait que les responsables de pip devraient annuler la récente version 19 pour résoudre ce changement majeur?
Notes de version 19.0: https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

MISE À JOUR: ne pas essayer de jeter des critiques ici, je suggérais simplement comme un moyen de débloquer rapidement les personnes affectées par cela, car la sortie avait eu lieu. La progression avec un correctif fonctionne également. J'apprécie le travail acharné de la communauté qui soutient cet outil essentiel à la mission, et je suis d'accord avec les sentiments ci-dessous concernant les post-mortems pour apprendre des erreurs et prévenir les problèmes futurs. Pendant ce temps, nous faisons la même chose en interne, ce qui signifie une quantité libérale de versions pip à tous les endroits :)

Le PR qui ajoute le commentaire TODO a également ce commentaire en réponse: https://github.com/pypa/pip/pull/5743/files#r215832743

Sur la base de ce commentaire et du commentaire ci-dessus disant que passer PYTHONOPTIMIZE=1 fait disparaître l'erreur, il semble que simplement supprimer l'assertion pourrait être la bonne solution (indépendamment de la question de la restauration).

Ouais, quand je supprime cette affirmation, les packages s'installent correctement avec --no-cache-dir . Dans ce cas, il dit que c'est Running setup.py install au lieu de Building wheel pour les packages sdist.

Cela arrive également à mes projets. Je peux reproduire cela dans des images Docker construites FROM ubuntu:bionic et FROM centos:centos7 où j'installe Python 3 à partir de la source (voici un Gist qui montre un exemple d'échec pour ces deux images Docker dans le cas où il pourrait être utile). Pour le requirements.txt dans l'exemple dans le Gist et

$ pip3 install --upgrade pip setuptools wheel
Requirement already up-to-date: pip in /usr/lib/python3.6/site-packages (19.0)
Requirement already up-to-date: setuptools in /usr/lib/python3.6/site-packages (40.6.3)
Requirement already up-to-date: wheel in /usr/lib/python3.6/site-packages (0.32.3)

puis

$ pip3 install --upgrade --no-cache-dir -r requirements.txt

échoue avec

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

mais

$ pip3 install --upgrade -r requirements.txt

fonctionne bien comme prévu.

Je le frappe particulièrement avec tox + docker + ENV PIP_NO_CACHE_DIR=off

Ma solution de contournement consiste à utiliser le plugin tox-virtualenv-no-download pour empêcher pip de se mettre à jour automatiquement

Nous avons également --no-cache-dir dans nos installations dans Docker pour garder les images petites. Notre solution de contournement a été --cache-dir=/pipcache , puis rm -rf /pipcache dans la même étape RUN afin qu'elle ne finisse jamais dans l'image.

Le développement de logiciels est difficile et des bugs comme celui-ci vont toujours se produire. Personne ne devrait certainement blâmer les responsables ou contributeurs de pip pour cet incident.

Cependant, je suggérerais que ce bogue mérite une sorte d'analyse post-mortem de la part de l'équipe pip, en raison du nombre d'opportunités (manquées) pour que ce bogue ait été détecté avant de glisser dans une version générale. Par exemple:

• test automatisé des fonctionnalités de base telles que --no-cache-dir
• contrôles pré-commit, pré-fusion ou pré-publication qui signalent (ou interdisent) TODO s
• un examen (humain) avant la fusion de tous les commentaires de révision non résolus dans le PR (Github automatise automatiquement la plupart des fils de commentaires de révision lorsque leur code associé a été modifié et vous permet récemment de marquer manuellement les fils de commentaires de révision comme résolus)
• changements dans le processus de publication - pourquoi ne pas publier d'abord une version bêta et attendre plusieurs semaines avant une version générale?
• etc

Un post-mortem pourrait entraîner un certain nombre d'améliorations utiles pour garantir que les logiciels qui sont aussi essentiels au projet Python que pip ne seront pas livrés avec des bogues de cette ampleur à l'avenir.

Je peux reproduire ce bug. La suppression de --no-cache-dir le corrige. Comme je n'en veux pas dans mon image docker, j'utilise la solution proposée par @coderanger . Vive 🌈🍰🌈

Cela ressemble à un duplicata du numéro 6166

Reproduction rapide et facile du Dockerfile:

FROM buildpack-deps:buster
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends python3-dev && rm -rf /var/lib/apt/lists/*
RUN curl https://bootstrap.pypa.io/get-pip.py | python3 - --no-cache-dir

supprimer simplement l'assertion pourrait être la bonne solution

Pas exactement - je pense que nous devrions garder cela là pour les versions non éphémiques. Je vais déposer un PR correctif, une fois que j'aurai fini le petit déjeuner. :)

@pradyunsg vérifie mon PR pour un test échoué

Pour moi, pip v19.0 échouera à installer quoi que ce soit si l'option --no-cache (ou --no-cache-dir ) est utilisée.

J'ai déposé # 6171 comme correctif pour ce problème. Les membres de ce fil pourraient-ils essayer ce PR et vérifier qu'il résout effectivement ce problème?

PS: Merci @tgs pour avoir déposé un PR pour aider à résoudre ce problème rapidement! :)

wfm, merci pour le correctif!

$ pip install pip --upgrade
Requirement already up-to-date: pip in ./venv/lib/python3.6/site-packages (19.0)
$ pip install --no-cache-dir pip
Requirement already satisfied: pip in ./venv/lib/python3.6/site-packages (19.0)
Exception:
Traceback (most recent call last):
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
$ pip install git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
Collecting git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
  Cloning https://github.com/pradyunsg/pip (to revision fix/pep-517-building-assertion) to ./pip-req-build-g_3qep31
Branch 'fix/pep-517-building-assertion' set up to track remote branch 'fix/pep-517-building-assertion' from 'origin'.
Switched to a new branch 'fix/pep-517-building-assertion'
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: pip
  Building wheel for pip (PEP 517) ... done
  Stored in directory: /tmp/pip-ephem-wheel-cache-sb1_muik/wheels/bd/86/cd/7688dba746eabc598fb37d4a93e2ff9bd05a6d9f907ee7b6cd
Successfully built pip
Installing collected packages: pip
  Found existing installation: pip 19.0
    Uninstalling pip-19.0:
      Successfully uninstalled pip-19.0
Successfully installed pip-19.1.dev0
$ pip install --no-cache-dir astpretty  # downloads a wheel
Collecting astpretty
  Downloading https://files.pythonhosted.org/packages/9d/10/cb0c3a3edb16f45be05bdba7f37798fcddb8cf085def8cb6e62b2ad7c711/astpretty-1.4.1-py2.py3-none-any.whl
Installing collected packages: astpretty
Successfully installed astpretty-1.4.1
$ pip install --no-cache-dir simplejson  # requires building
Collecting simplejson
  Downloading https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f88e85469004713dab488dee4f35b0aff/simplejson-3.16.0.tar.gz (81kB)
    100% |████████████████████████████████| 81kB 1.0MB/s 
Installing collected packages: simplejson
  Running setup.py install for simplejson ... done
Successfully installed simplejson-3.16.0

J'espère fusionner PR6171 bientôt et publier la version 19.0.1

Les gens devraient vraiment épingler pip dans CI comme vous le feriez pour tout autre package ou dépendance, IMO. Sinon, vous n'avez pas de reproductibilité et risquez de brusques ruptures. En épinglant, vous pouvez vérifier les choses à l'avance et mettre à niveau à votre rythme.

Les gens devraient vraiment épingler pip dans CI comme vous le feriez pour tout autre package ou dépendance, IMO. Sinon, vous n'avez pas de reproductibilité et risquez de brusques ruptures. En épinglant, vous pouvez vérifier les choses à l'avance et mettre à niveau à votre rythme.

@cjerdonek : Je suis d'accord avec vous que - du point de vue de l' utilisateur pip - c'est une bonne idée d'épingler pip dans de nombreux contextes (peut-être la plupart). À tout le moins, si vous n'épinglez pas, vous devez savoir que vous risquez exactement ce genre de choses, et vous ne pouvez pas vous plaindre aux responsables de pip si cela arrive!

Cependant ... du point de vue du mainteneur de pip (et plus largement du point de vue de l'équipe de base PyPA ou Python), je pense qu'il serait prudent de voir le fait qu'un grand nombre de personnes n'épinglent pas pip comme un atout. C'est intangible, mais démontre une grande confiance de la base d'utilisateurs. (En aparté, peut-être contre-intuitif, d'après mon expérience, il arrive souvent que les outils les plus essentiels ne soient

Des incidents comme celui-ci érodent cette confiance. Les builds CI cassés ne sont pas le problème réel (comme vous le dites, vous devez soit épingler pip dans les builds CI ou être conscient de ce que vous risquez), mais sont un symptôme - ou plutôt, un avertissement corrélé - de cette confiance érodée.

C'est pourquoi j'ai proposé que cet incident mérite une sorte de processus post-mortem (irréprochable). Aucun mainteneur de pip ne devrait se sentir mal en ce moment, mais c'est un problème sérieux et devrait être examiné pour des améliorations.

Ouais, des incidents comme celui-ci n'aident pas à instaurer la confiance. Nous aurons un post mortem pour savoir comment les éviter (nous le faisons après chaque sortie car il y a toujours place à l'amélioration).

Merci pour (surtout) maintenir un discours approprié et pour vos commentaires constructifs! Habituellement, les choses sont beaucoup plus corrosives pour nous quand il y a un problème comme celui-ci. :)

Néanmoins, il y a quelques autres rapports de bogues à examiner et nous aurons bientôt un 19.0.1.

Je pense que l'essentiel ici est que cela a révélé que nous n'avons pas suffisamment de tests pour construire sous --no-cache-dir . Des tests supplémentaires dans ce domaine seraient d'une grande aide pour éviter des régressions comme celle-ci, et plus généralement un examen de la fonctionnalité «clé» sous-testée serait utile.

En tant que mainteneur de pip, je dirais qu'un problème que j'ai est de savoir ce que les gens considèrent comme une fonctionnalité «clé». Personnellement, j'aurais supposé que --no-cache-dir était assez niche, donc évidemment mon intuition n'est pas fiable dans ce cas :-) Par conséquent, des commentaires comme celui-ci sont particulièrement précieux.

Je pense que la version 19.0.1 ne pourra bientôt sortir que pour ce bug, après tout, c'est important et urgent. Un autre rapport de bogue peut être résolu en 19.0.2 après jour.

En tant que mainteneur de pip, je dirais qu'un problème que j'ai est de savoir ce que les gens considèrent comme une fonctionnalité «clé». Personnellement, j'aurais supposé que --no-cache-dir était assez niche, donc évidemment mon intuition n'est pas fiable dans ce cas :-) Par conséquent, des commentaires comme celui-ci sont particulièrement précieux.

La seule raison pour laquelle j'utilise --no-cache-dir , c'est pour installer mpi4py .
De cette façon, je peux faire en sorte qu'il soit retéléchargé et reconstruit avant l'installation, en m'assurant que toutes les modifications apportées à ma distribution MPI sont prises en compte.

Même problème ici, capable de le reproduire en dehors de notre système CI. Pour contourner le problème, nous avons rétrogradé à pip 18.1.0 et tout fonctionne:

pip install pip==18.1.0

Espoir et mise à niveau bientôt.

J'utiliserai:

pip install "pip!=19.0"

Hope 19.1 est corrigé :)

Je suppose que nous aurons un 19.0.1 relativement bientôt avec des correctifs pour les problèmes émergents.

Je suis curieux de savoir si l'inclusion de --no-use-pep517 avec --no-cache-dir est une autre solution pour ce problème, comme c'est le cas pour un autre problème lié à PEP 517: https://github.com/pypa/pip / issues / 6163 # issuecomment -456772043

En tant que mainteneur de pip, je dirais qu'un problème que j'ai est de savoir ce que les gens considèrent comme une fonctionnalité «clé». Personnellement, j'aurais supposé que --no-cache-dir était assez niche, donc évidemment mon intuition n'est pas fiable dans ce cas :-) Par conséquent, des commentaires comme celui-ci sont particulièrement précieux.

FWIW: J'utilise --no-cache-dir assez souvent lors de la création d'images Docker, pour éviter les risques de laisser des cachettes dans un environnement où cela ne sera pas utile.

Les gens devraient vraiment épingler pip dans CI comme vous le feriez pour tout autre package ou dépendance, IMO. Sinon, vous n'avez pas de reproductibilité et risquez de brusques ruptures. En épinglant, vous pouvez vérifier les choses à l'avance et mettre à niveau à votre rythme.

Dans de nombreux environnements, pip n'est pas une dépendance. Il est installé lors de la création du virtualenv.

Et en passant, il n'y a pas de test pour voir si votre produit fonctionne avec les versions les plus récentes. Tout épingler ne conduit qu'à d'anciennes versions utilisées. Et la mise à jour sera bientôt une tâche que personne n'ose entreprendre. J'y suis allé, j'ai fait ça. Donc, mon avis est d'épingler seulement si vraiment nécessaire. Et essayez de résoudre le problème dès qu'ils se produisent.

pip 19.0.1 est sorti avec le correctif de ce problème.

J'étais ravi de voir le nouveau correctif de la version 19.0.1, mais j'avais toujours un problème. Je crée également une image Docker avec --no-cache-dir qui fonctionne bien avec pip <19.0. Quelqu'un d'autre a compris ça?

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError

J'étais ravi de voir le nouveau correctif de la version 19.0.1, mais j'avais toujours un problème. Je crée également une image Docker avec --no-cache-dir qui fonctionne bien avec pip <19.0. Quelqu'un d'autre a compris ça?

le correctif fonctionne pour moi avec 19.0.1 - Je suppose que vous avez un cache de couche docker qui vous déroute? - essayez pip --version pour vérifier la version que vous utilisez

J'ai une vérification de version Python et pip dans tous mes fichiers Docker, et il signale correctement 19.0.1.

@dmulter J'ai reconstruit mes images Docker dans mon Gist à partir de zéro ce matin et les choses fonctionnent bien là-bas avec v19.0.1 . Pouvez-vous partager votre Dockerfile dans un Gist afin que nous puissions tous le regarder?

Je viens de tout nettoyer à nouveau pour être sûr. Voici le Dockerfile et ma sortie de construction .

Voir ma note sur la sortie de construction pour les commandes docker qui ont été utilisées.

Existe-t-il un correctif pour pip3? Voici l'erreur que j'ai eue ...

> pip3 install --upgrade 'pip>=19.01' setuptools

  Could not find a version that satisfies the requirement pip>=19.01 (from versions: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.8.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.3, 1.3.1, 1.4, 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.1.0, 6.1.1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.1.2, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.1.0, 8.1.1, 8.1.2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 10.0.0b1, 10.0.0b2, 10.0.0, 10.0.1, 18.0, 18.1, 19.0)
No matching distribution found for pip>=19.01
You are using pip version 10.0.1, however version 19.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

@MrAtheist Vous avez une petite faute de frappe / il manque une décimale. La version du correctif est 19.0.1 mais vous avez écrit 19.01 .

oups mon erreur, mais de toute façon, les versions possibles n'ont pas 19.0.1 listées ... ¯_ (ツ) _ / ¯

Comme @dmulter, je trouve que le problème

. venv/bin/activate;  python -m pip install --upgrade pip; python -m pip install ndg_httpsclient; python -m pip install . -i https://xxxx.yyyy.com/simple --upgrade --no-cache-dir flask
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Requirement already up-to-date: pip in ./venv/lib/python2.7/site-packages (19.0.1)
...
Requirement already satisfied, skipping upgrade: pycparser in ./venv/lib/python2.7/site-packages (from cffi>=1.1->bcrypt>=3.1.3->paramiko<3.0,>=1.10->Fabric==1.14.0->conference-gll-load-test===0.0.1-SNAPSHOT) (2.19)
Exception:
Traceback (most recent call last):
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError
make: *** [install] Error 2

Plus tôt dans le fil de discussion, j'avais demandé si l'inclusion de --no-use-pep517 avec --no-cache-dir faisait fonctionner les choses pour les gens, mais je n'ai pas vu de réponse. Pour les personnes qui utilisent encore cette option, pouvez-vous l'essayer?

L'ajout de l'option --no-use-pep517 résolu le problème pour moi. J'espère que cela aidera à affiner les choses.

pip 19.0.1 fonctionne pour moi dans un virtualenv. Mais à l'intérieur de Jenkins (Shining Panda), cela échoue toujours. L'ajout de --no-use-pep517 résout le problème

Je rouvre car certaines personnes rencontrent toujours le même problème.

Je peux également confirmer que --no-use-pep517 résolu le problème pour moi après la mise à niveau vers pip 19.0.1 ne l'a pas fait.

Mais pourquoi tous ces projets doivent-ils s'adapter chaque fois que pip obtient une nouvelle version?

À la demande de @pradyunsg , j'ai ouvert un nouveau numéro (https://github.com/pypa/pip/issues/6197) spécifique au AssertionError dans la version 19.0.1, car il est plus restreint de portée et nécessitera une nouvelle enquête. Je referme donc ce numéro.

Ran dans le même problème. J'ai fini par épingler la version pip comme correctif pour le moment.

pip install --upgrade pip==18.1

ou votre FROM python:3.6-alpine peut changer en FROM python:3.6.7-alpine

Ce thread a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau numéro pour les bogues associés.