Pip: afirmación al usar --no-cache-dir en 19.0

Lo mismo sucede con:
Python v3.6.8
pip version 18.1
en
Ubuntu:latest imagen.

@snstanton ¿qué imagen base estás usando? También veo un problema similar en pip v18.1

Tengo exactamente el mismo problema.
por mi parte, parece que no importa qué paquete / distribución trate de instalar

Veo esto incluso sin --no-cache-dir establecido. Sucede para todos los paquetes que intento instalar, incluso si ya están instalados.

• versión pip: 19.0
• Versión de Python: 3.6.0
• SO: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-genérico x86_64)

Debo notar que en mi caso lo veo cuando ejecuto pip con una combinación de sudo -H y 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

Ejecutando los mismos comandos sin -l en mi bash -c , o sin bash -l -c involucrado en absoluto, todo funciona 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

De manera fascinante, si ejecuto el mismo comando sin sudo o bash involucrados en absoluto, todavía falla con el mismo error, por lo que parece que tal vez sea un problema de permisos extraño.

Otra solución para algunas situaciones

Para las personas que tienen este error porque virtualenv está instalando automáticamente la última versión de pip, puede solucionarlo dando a virtualenv la opción --no-download , o configurando VIRTUALENV_NO_DOWNLOAD=1 .

Pero tenga en cuenta que esto puede darle una versión muy antigua de pip, dependiendo de la última vez que haya actualizado virtualenv.

Esto también funciona con tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

por lo que vale: también falla con el mismo error si el paquete ya está instalado:

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$

Me encontré con el mismo problema. Terminé fijando la versión pip como una solución por ahora.

pip install --upgrade pip==18.1

El problema es que no se puede afirmar, por lo que establecer env PYTHONOPTIMIZE = 1 (o con el parámetro -O) hace que este error desaparezca.
Solo lo probé.
Esta solución funciona porque Python optimiza el código eliminando todas las afirmaciones como una de las cosas.
No opte por = 2 (o -OO), ya que esto elimina las cadenas de documentos y aparecerán otros rastreos; algún código quiere operar en ellos.

Parece que alguien sabía que esto podría terminar siendo un problema ( fuente ):

        # 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 parece que este es un cambio relacionado que podría haber causado esto.

¿Parece que los mantenedores de pips deberían revertir la reciente versión 19 para abordar este cambio radical?
Notas de la versión 19.0: https://github.com/pypa/pip/blob/master/NEWS.rst#190-2019-01-22

ACTUALIZACIÓN: no estoy tratando de lanzar calumnias aquí, solo estaba sugiriendo como una forma de desbloquear rápidamente a las personas afectadas por esto, ya que el lanzamiento acababa de ocurrir. Avanzar con una revisión también funciona. Aprecio el arduo trabajo de la comunidad que apoya esta herramienta de misión crítica y estoy de acuerdo con los sentimientos a continuación sobre las autopsias para aprender de los errores y prevenir problemas futuros. Mientras tanto, estamos haciendo lo mismo internamente, lo que significa una cantidad liberal de versiones pip hardpinning en todos los lugares :)

El RP que agrega el comentario TODO también tiene este comentario en respuesta: https://github.com/pypa/pip/pull/5743/files#r215832743

Según ese comentario y también el comentarista anterior que dice que pasar PYTHONOPTIMIZE=1 hace que el error desaparezca, parece que simplemente eliminar la afirmación podría ser la solución correcta (independientemente de la cuestión de retroceder).

Sí, cuando elimino esa afirmación, los paquetes se instalan bien con --no-cache-dir . En ese caso, dice que es Running setup.py install lugar de Building wheel para los paquetes sdist.

Esto también está sucediendo con mis proyectos. Puedo reproducir esto en imágenes de Docker compiladas FROM ubuntu:bionic y FROM centos:centos7 donde estoy instalando Python 3 desde la fuente (aquí hay un Gist que demuestra un ejemplo de falla para ambas imágenes de Docker en caso de que podría ser útil). Para el requirements.txt en el ejemplo de Gist y

$ 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)

luego

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

falla con

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

pero

$ pip3 install --upgrade -r requirements.txt

funciona bien como se esperaba.

Particularmente estoy golpeando esto con tox + docker + ENV PIP_NO_CACHE_DIR=off

Mi solución es usar el complemento tox-virtualenv-no-download para evitar que pip se actualice automáticamente

También tenemos --no-cache-dir en nuestras instalaciones dentro de Docker para mantener las imágenes pequeñas. Nuestra solución ha sido --cache-dir=/pipcache y luego rm -rf /pipcache en el mismo paso RUN para que nunca termine en la imagen.

El desarrollo de software es difícil y errores como este siempre van a ocurrir. Ciertamente, nadie debería culpar a los mantenedores o contribuyentes de pip por este incidente.

Sin embargo, sugeriría que este error merece algún tipo de análisis post-mortem por parte del equipo de pip, debido a la cantidad de oportunidades (perdidas) para que este error se haya detectado antes de pasar a una versión general. Por ejemplo:

• pruebas automatizadas de funciones básicas como --no-cache-dir
• comprobaciones previas a la confirmación, combinación o publicación previa que marcan (o prohíben) TODO s
• una revisión (humana) previa a la fusión de todos los comentarios de revisión no resueltos en el PR (Github minimiza automáticamente la mayoría de los hilos de comentarios de revisión cuando se ha cambiado su código asociado, y recientemente le permite marcar manualmente los hilos de comentarios de revisión como resueltos)
• cambios en el proceso de lanzamiento: ¿por qué no lanzar una versión beta primero y luego esperar varias semanas antes de un lanzamiento general?
• etc

Una autopsia podría resultar en una serie de mejoras útiles para garantizar que el software que es tan básico para el proyecto Python como pip no se envíe con errores de esta magnitud en el futuro.

Puedo replicar este error. Eliminar --no-cache-dir lo corrige. Como no lo quiero en mi imagen de Docker, estoy usando la solución que propuso

Parece un duplicado del número 6166.

Dockerfile de reproducción rápida y sencilla:

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

simplemente eliminar la aserción podría ser la solución correcta

No exactamente, creo que deberíamos mantener esto ahí para las compilaciones que no son de ephem. Presentaré una corrección de errores de PR, una vez que termine con el desayuno. :)

@pradyunsg revisa mi PR para una prueba fallida

Para mí, pip v19.0 no instalará nada si se usa la opción --no-cache (o --no-cache-dir ).

Presenté el número 6171 como corrección de errores para este problema. ¿Podrían las personas de este hilo probar ese PR y verificar que realmente soluciona este problema?

PD: ¡Gracias @tgs por presentar un PR para ayudar a solucionar este problema rápidamente! :)

wfm, ¡gracias por la solución!

$ 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

Espero fusionar PR6171 pronto y lanzar la versión 19.0.1

La gente debería fijar pip en CI como lo haría con cualquier otro paquete o dependencia, en mi opinión. De lo contrario, no tiene reproducibilidad y corre el riesgo de roturas repentinas. Al fijar, puede verificar las cosas con anticipación y actualizar a su propio ritmo.

La gente debería fijar pip en CI como lo haría con cualquier otro paquete o dependencia, en mi opinión. De lo contrario, no tiene reproducibilidad y corre el riesgo de roturas repentinas. Al fijar, puede verificar las cosas con anticipación y actualizar a su propio ritmo.

@cjerdonek : Estoy de acuerdo con usted en que, desde la perspectiva del pip , es una buena idea fijar pip en muchos (quizás la mayoría) contextos. Por lo menos, si no fijas, debes saber que estás arriesgando exactamente este tipo de cosas, ¡y no puedes quejarte con los mantenedores de pip si esto sucede!

Sin embargo ... desde una perspectiva de pip mantenedor (y más ampliamente desde una perspectiva de equipo central de PyPA o Python) creo que sería prudente ver el hecho de que muchas personas no fijan pip como activo. Es intangible, pero demuestra una gran confianza por parte de la base de usuarios. (Como acotación al margen, quizás de manera contradictoria, en mi experiencia, a menudo ocurre que la mayoría de las herramientas principales no están ancladas como la mayoría de las dependencias. Por ejemplo, donde trabajo, Python en sí mismo generalmente se fija de manera efectiva a una versión menor: las nuevas versiones de parche obtienen automáticamente recogido por las nuevas compilaciones. Creo que esto muestra el elevado nivel de confianza que los usuarios tienen en estas herramientas básicas y su mantenimiento).

Incidentes como este erosionan esa confianza. Las compilaciones de CI rotas no son el problema real (como usted dice, debe fijar pip en compilaciones de CI o ser consciente de lo que está arriesgando), pero son un síntoma, o más bien, una advertencia correlacionada, de que erosionó la confianza.

Por eso propuse que este incidente amerita algún tipo de proceso post mortem (sin culpa). Ningún mantenedor de pip debería sentirse mal en este momento, pero este es un problema grave y debería examinarse en busca de mejoras.

Sí, incidentes como este no ayudan a generar confianza. Tendremos una autopsia para descubrir cómo evitarlos (lo hacemos después de cada lanzamiento porque siempre hay margen de mejora).

¡Gracias por (principalmente) mantener un discurso adecuado y por los comentarios constructivos! Por lo general, las cosas son mucho más corrosivas para nosotros cuando hay un problema como este. :)

No obstante, hay un par de informes de errores más para examinar y pronto tendremos una 19.0.1.

Creo que la clave aquí es que esto ha expuesto que no tenemos suficientes pruebas para construir bajo --no-cache-dir . Las pruebas adicionales en esa área serían de gran ayuda para evitar regresiones como esta y, de manera más general, sería útil una revisión de qué funcionalidad "clave" no está probada correctamente.

Como mantenedor de pip, diría que un problema que tengo es saber qué es lo que la gente considera funcionalidad "clave". Personalmente, habría asumido que --no-cache-dir era bastante nicho, así que obviamente mi intuición no es confiable en este caso :-) Por lo tanto, comentarios como este son particularmente valiosos.

Creo que pronto se lanzará la 19.0.1 sólo para este error, después de todo, es importante y urgente. Otros informes de errores se pueden resolver en 19.0.2 después del día.

Como mantenedor de pip, diría que un problema que tengo es saber qué es lo que la gente considera funcionalidad "clave". Personalmente, habría asumido que --no-cache-dir era bastante nicho, por lo que obviamente mi intuición no es confiable en este caso :-) Por lo tanto, comentarios como este son particularmente valiosos.

La única razón por la que uso --no-cache-dir es para instalar mpi4py .
De esta manera, puedo hacer que se vuelva a descargar y reconstruir antes de instalar, asegurándome de que se tengan en cuenta los cambios realizados en mi distribución MPI.

El mismo problema aquí, capaz de reproducirlo fuera de nuestro sistema de CI. Como solución alternativa, hemos rebajado a pip 18.1.0 y todo funciona:

pip install pip==18.1.0

Espero y actualiza pronto.

Usaré:

pip install "pip!=19.0"

Hope 19.1 está arreglado :)

Sospecho que tendremos una 19.0.1 relativamente pronto con correcciones para los problemas emergentes.

Tengo curiosidad si incluir --no-use-pep517 junto con --no-cache-dir es otra solución para este problema, como lo es para otro problema relacionado con PEP 517: https://github.com/pypa/pip / issues / 6163 # issuecomment -456772043

Como mantenedor de pip, diría que un problema que tengo es saber qué es lo que la gente considera funcionalidad "clave". Personalmente, habría asumido que --no-cache-dir era bastante nicho, así que obviamente mi intuición no es confiable en este caso :-) Por lo tanto, comentarios como este son particularmente valiosos.

FWIW: Utilizo --no-cache-dir bastante frecuencia cuando construyo imágenes de Docker, para evitar las posibilidades de que cualquier elemento de caché se quede en un entorno donde no será útil.

La gente debería fijar pip en CI como lo haría con cualquier otro paquete o dependencia, en mi opinión. De lo contrario, no tiene reproducibilidad y corre el riesgo de roturas repentinas. Al fijar, puede verificar las cosas con anticipación y actualizar a su propio ritmo.

En muchos entornos, pip no es una dependencia. Se instala al crear virtualenv.

Y, por cierto, no está probando allí para ver si su producto funciona con las versiones más recientes. Anclar todo solo lleva a que se utilicen versiones antiguas. Y la actualización pronto será una tarea que nadie se atreva a emprender. He estado allí, he hecho eso. Entonces mi opinión es fijar solo si es realmente necesario. E intente solucionar el problema tan pronto como se produzcan.

pip 19.0.1 está disponible con la solución para este problema.

Estaba emocionado de ver la nueva corrección de la versión 19.0.1, pero todavía tengo un problema. También estoy creando una imagen de Docker con --no-cache-dir que funciona bien con pip <19.0. ¿Alguien más está recibiendo esto?

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

Estaba emocionado de ver la nueva corrección de la versión 19.0.1, pero todavía tengo un problema. También estoy creando una imagen de Docker con --no-cache-dir que funciona bien con pip <19.0. ¿Alguien más está recibiendo esto?

La solución me funciona con 19.0.1. ¿Sospecho que tienes una caché de capa de docker que te confunde? - prueba pip --version para comprobar en qué versión estás

Tengo una verificación de la versión de Python y pip en todos mis archivos de Docker, e informa 19.0.1 correctamente.

@dmulter Reconstruí mis imágenes de Docker en mi Gist desde cero esta mañana y las cosas están funcionando bien allí con v19.0.1 . ¿Puedes compartir tu Dockerfile en un Gist también para que todos podamos verlo?

Limpié todo de nuevo para estar seguro. Aquí está el Dockerfile y mi salida de compilación .

Consulte mi nota sobre el resultado de la compilación de los comandos de la ventana acoplable que se utilizaron.

¿Existe una solución para pip3? Aquí está el error que tengo ...

> 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 Tiene un pequeño error tipográfico / falta un decimal. La versión del parche es 19.0.1 pero tienes 19.01 escrito.

Ups mi error, pero de cualquier manera, las posibles versiones no tienen 19.0.1 lista ...

Como @dmulter , encuentro que el problema aún no está resuelto. Extracto de la salida de la compilación:

. 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

Anteriormente en el hilo , había preguntado si incluir --no-use-pep517 junto con --no-cache-dir hace que las cosas funcionen para las personas, pero no vi una respuesta. Para las personas que todavía están experimentando la opción, ¿pueden intentarlo?

Agregar la opción --no-use-pep517 solucionó el problema. Espero que ayude a reducir las cosas.

pip 19.0.1 trabajando para mí en un virtualenv. Pero dentro de Jenkins (Shining Panda) todavía falla. Agregar --no-use-pep517 soluciona el problema

Voy a reabrir porque algunas personas todavía tienen el mismo problema.

También puedo confirmar que --no-use-pep517 solucionó el problema después de actualizar a pip 19.0.1 no lo hizo.

Pero, ¿por qué todos esos proyectos tienen que adaptarse cada vez que pip obtiene una nueva versión?

A petición de , abrí un nuevo número (https://github.com/pypa/pip/issues/6197) específico para AssertionError en la versión 19.0.1, ya que es más limitado en alcance y necesitará una nueva investigación. Así que vuelvo a cerrar este problema.

Me encontré con el mismo problema. Terminé fijando la versión pip como una solución por ahora.

pip install --upgrade pip==18.1

o su FROM python:3.6-alpine puede cambiar a FROM python:3.6.7-alpine

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.