Pip: afirmação ao usar --no-cache-dir em 19.0

A mesma coisa acontece com:
Python v3.6.8
pip version 18.1
em
Ubuntu:latest .

@snstanton que imagem base você está usando? Estou vendo um problema semelhante no pip v18.1 também

Eu tenho exatamente o mesmo problema.
do meu lado, parece que não importa qual pacote / distribuição eu tento instalar

Estou vendo isso mesmo sem --no-cache-dir definido. Acontece com todos os pacotes que tento instalar, mesmo que já estejam instalados.

• versão pip: 19.0
• Versão Python: 3.6.0
• SO: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-genérico x86_64)

Devo observar que, no meu caso, estou vendo isso ao executar pip com uma combinação de sudo -H e 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

Executando os mesmos comandos sem -l no meu bash -c , ou sem bash -l -c envolvido em tudo, tudo funciona bem.

$ 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

Fascinantemente, se eu executar o mesmo comando sem sudo ou bash envolvidos, ele ainda falhará com o mesmo erro, então parece que é algum problema estranho de permissões, talvez.

Outra solução alternativa para algumas situações

Para as pessoas que encontraram esse bug porque o virtualenv está instalando automaticamente a versão mais recente do pip, você pode contornar isso dando ao virtualenv a opção --no-download ou definindo VIRTUALENV_NO_DOWNLOAD=1 .

Mas esteja ciente de que isso pode fornecer a você uma versão muito antiga do pip, dependendo da última vez que você atualizou o virtualenv.

Isso também funciona com tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

pelo que vale a pena: também falha com o mesmo erro se o pacote já estiver 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$

Encontrou o mesmo problema. Acabou fixando a versão do pip como uma correção por enquanto.

pip install --upgrade pip==18.1

O problema é com falha na declaração, portanto, definir env PYTHONOPTIMIZE = 1 (ou com o parâmetro -O) faz com que esse erro desapareça.
Apenas testei.
Essa solução alternativa funciona porque o python otimiza o código removendo todas as declarações como uma das coisas.
Não vá para = 2 (ou -OO), pois isso remove docstrings e outros rastreios aparecerão - algum código deseja operar neles.

Parece que alguém sabia que isso pode acabar sendo um problema ( fonte ):

        # 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 esta é uma alteração relacionada que pode ter causado isso?

Parece que os mantenedores do pip deveriam reverter a versão 19 recente para resolver essa mudança significativa?
19.0 notas da versão: https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

ATUALIZAÇÃO: não estou tentando lançar calúnias aqui, estava apenas sugerindo como uma maneira de desbloquear rapidamente as pessoas afetadas por isso, visto que o lançamento havia _just_ acontecido. Avançar com um hotfix também funciona. Agradeço o trabalho árduo da comunidade que apóia esta ferramenta de missão crítica e concordo com os sentimentos abaixo sobre autópsias para aprender com os erros e evitar problemas futuros. Enquanto isso, estamos fazendo o mesmo internamente, o que significa uma quantidade generosa de versões pip fixas em todos os lugares :)

O PR que adiciona o comentário TODO também tem este comentário em resposta: https://github.com/pypa/pip/pull/5743/files#r215832743

Com base nesse comentário e também no comentador acima dizendo que passar PYTHONOPTIMIZE=1 faz o erro desaparecer, parece que simplesmente remover a afirmação pode ser a correção correta (independente da questão de reverter).

Sim, quando excluo essa declaração, os pacotes são instalados sem problemas com --no-cache-dir . Nesse caso, diz que é Running setup.py install vez de Building wheel para pacotes sdist.

Isso também está acontecendo com meus projetos. Posso reproduzir isso em imagens Docker construídas FROM ubuntu:bionic e FROM centos:centos7 onde estou instalando Python 3 a partir da fonte (aqui está um Gist que demonstra um exemplo de falha para ambas as imagens Docker no caso de pode ser útil). Para requirements.txt no exemplo no Síntese e

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

então

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

falha com

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

mas

$ pip3 install --upgrade -r requirements.txt

funciona bem conforme o esperado.

Estou particularmente acertando isso com tox + docker + ENV PIP_NO_CACHE_DIR=off

Minha solução alternativa é usar o plugin tox-virtualenv-no-download para evitar que o pip se atualize automaticamente

Também temos --no-cache-dir em nossas instalações dentro do Docker para manter as imagens pequenas. Nossa solução alternativa foi --cache-dir=/pipcache e, em seguida, rm -rf /pipcache na mesma etapa de RUN para que nunca acabe na imagem.

O desenvolvimento de software é difícil e bugs como esse sempre vão acontecer. Certamente ninguém deve culpar os pip mantenedores ou contribuintes por este incidente.

No entanto, eu sugeriria que esse bug merece algum tipo de análise post-mortem por parte da equipe do pip, devido ao número de oportunidades (perdidas) para esse bug ter sido detectado antes de deslizar para uma versão geral. Por exemplo:

• teste automatizado de funcionalidade central, como --no-cache-dir
• verificações de pré-confirmação, pré-mesclagem ou pré-lançamento que sinalizam (ou proíbem) TODO s
• uma revisão (humana) pré-mesclagem de todos os comentários de revisão não resolvidos no PR (o Github automatiza a maioria dos tópicos de comentários de revisão quando seu código associado foi alterado e, recentemente, permite que você marque manualmente os tópicos de comentários de revisão como resolvidos)
• mudanças no processo de lançamento - por que não lançar um beta primeiro e depois esperar várias semanas antes de um lançamento geral?
• etc

Uma autópsia pode resultar em uma série de melhorias úteis para garantir que o software que é tão importante para o projeto Python quanto pip não seja entregue com bugs dessa magnitude no futuro.

Eu posso replicar esse bug. Remover --no-cache-dir corrige isso. Como não quero isso na imagem do docker, estou usando a solução proposta por @coderanger . Saúde 🌈🍰🌈

Parece uma duplicata do problema # 6166

Dockerfile de reprodução rápida e fácil:

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

simplesmente remover a asserção pode ser a correção correta

Não exatamente - acho que devemos manter isso lá para as compilações não efémicas. Vou registrar uma RP de correção de bug, assim que terminar o café da manhã. :)

@pradyunsg verifique meu PR para ver se há reprovação

Para mim, o pip v19.0 não conseguirá instalar nada se a opção --no-cache (ou --no-cache-dir ) for usada.

Registrei o número 6171 como uma correção de bug para esse problema. O pessoal deste tópico poderia experimentar esse PR e verificar se ele realmente corrige o problema?

PS: Obrigado @tgs por preencher um PR para ajudar a corrigir esse problema rapidamente! :)

wfm, obrigado pela correção!

$ 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 mesclar PR6171 em breve e lançar a versão 19.0.1

As pessoas realmente deveriam colocar pip no CI como você faria com qualquer outro pacote ou dependência, IMO. Caso contrário, você não tem reprodutibilidade e corre o risco de quebras repentinas. Ao fixar, você pode verificar as coisas com antecedência e atualizar no seu próprio ritmo.

As pessoas realmente deveriam colocar pip no CI como você faria com qualquer outro pacote ou dependência, IMO. Caso contrário, você não tem reprodutibilidade e corre o risco de quebras repentinas. Ao fixar, você pode verificar as coisas com antecedência e atualizar no seu próprio ritmo.

@cjerdonek : Eu concordo com você que - da perspectiva do usuário pip - é uma boa idéia fixar pip em muitos (talvez na maioria) contextos. No mínimo, se você não fixar, deve saber que está se arriscando exatamente a esse tipo de coisa e não pode reclamar com os pip mantenedores se isso acontecer!

No entanto ... de uma perspectiva de mantenedor de pip (e mais amplamente de uma perspectiva de equipe central de PyPA ou Python), acho que seria prudente ver o fato de que muitas pessoas não fixam pip como um ativo. É intangível, mas demonstra grande confiança da base de usuários. (Como um aparte, talvez contra-intuitivamente, na minha experiência é frequentemente o caso de que a maioria das ferramentas principais não são fixadas como a maioria das dependências. Por exemplo, onde eu trabalho, o próprio python é geralmente efetivamente fixado em uma versão secundária - novas versões de patch obtêm automaticamente adquirido por novas compilações. Acho que isso mostra o elevado nível de confiança que os usuários têm nessas ferramentas principais e sua manutenção.)

Incidentes como esse corroem essa confiança. Os builds de CI quebrados não são o problema real (como você diz, você deve fixar pip em builds de CI ou estar ciente do que está arriscando), mas são um sintoma - ou melhor, um aviso correlato - de que corroeu a confiança.

É por isso que propus que este incidente merece algum tipo de processo post-mortem (sem culpa). Nenhum mantenedor de pip deve estar se sentindo mal agora, mas, este é um problema sério e deve ser examinado para melhorias.

Sim, incidentes como este não ajudam a construir confiança. Teremos uma autópsia para descobrir como evitá-los (fazemos isso após cada lançamento porque sempre há espaço para melhorias).

Obrigado por (principalmente) manter um discurso adequado e pelos comentários construtivos a todos! Normalmente, as coisas são muito mais corrosivas para nós quando há um problema como este. :)

No entanto, há alguns outros relatórios de bug para examinar e teremos um 19.0.1 em breve.

Acho que o principal aqui é que isso expôs que não temos testes suficientes para construir em --no-cache-dir . Testes adicionais nessa área seriam de grande ajuda para evitar regressões como essa e, de maneira mais geral, uma revisão de quais funcionalidades "chave" não foram testadas seria útil.

Como mantenedor do pip, eu diria que um problema que tenho é saber o que as pessoas consideram uma funcionalidade "chave". Pessoalmente, eu teria assumido que --no-cache-dir era um nicho razoável, então obviamente minha intuição não é confiável neste caso :-) Portanto, feedback como este é particularmente valioso.

Acho que em breve poderá ser lançado o 19.0.1 apenas por esse bug, afinal é significativo e urgente. Outro relatório de bug pode resolver em 19.0.2 após o dia.

Como mantenedor do pip, eu diria que um problema que tenho é saber o que as pessoas consideram uma funcionalidade "chave". Pessoalmente, eu presumiria que --no-cache-dir era um nicho razoável, então, obviamente, minha intuição não é confiável neste caso :-) Portanto, feedback como este é particularmente valioso.

A única razão pela qual uso --no-cache-dir é para instalar mpi4py .
Dessa forma, posso garantir que ele seja baixado novamente e reconstruído antes da instalação, certificando-me de que todas as alterações feitas em minha distribuição MPI sejam levadas em consideração.

Mesmo problema aqui, capaz de reproduzi-lo fora de nosso sistema de CI. Como solução alternativa, fizemos o downgrade para o pip 18.1.0 e tudo funciona:

pip install pip==18.1.0

Espero e atualize em breve.

Usarei:

pip install "pip!=19.0"

A esperança 19.1 foi corrigida :)

Suspeito que teremos um 19.0.1 relativamente em breve, com correções para os problemas emergentes.

Estou curioso para saber se a inclusão de --no-use-pep517 junto com --no-cache-dir é outra solução para esse problema, assim como para outro problema relacionado ao PEP 517: https://github.com/pypa/pip / issues / 6163 # issuecomment -456772043

Como mantenedor do pip, eu diria que um problema que tenho é saber o que as pessoas consideram uma funcionalidade "chave". Pessoalmente, eu teria assumido que --no-cache-dir era bastante nicho, então obviamente minha intuição não é confiável neste caso :-) Portanto, feedback como este é particularmente valioso.

FWIW: Eu uso --no-cache-dir bastante frequência ao construir imagens Docker, para evitar as chances de qualquer fragmento de cache ser deixado em um ambiente onde não será útil.

As pessoas realmente deveriam colocar pip no CI como você faria com qualquer outro pacote ou dependência, IMO. Caso contrário, você não tem reprodutibilidade e corre o risco de quebras repentinas. Ao fixar, você pode verificar as coisas com antecedência e atualizar no seu próprio ritmo.

Em muitos ambientes, o pip não é uma dependência. É instalado durante a criação do virtualenv.

E por falar nisso, não está testando lá para ver se seu produto funciona com as versões mais recentes. Fixar tudo leva apenas a versões antigas usadas. E atualizar em breve será uma tarefa que ninguém ousa iniciar. Já estive lá, fiz isso. Portanto, minha opinião é fixar apenas se for realmente necessário. E tente consertar o problema assim que eles ocorrerem.

O pip 19.0.1 lançou a correção para esse problema.

Fiquei animado para ver a nova correção da versão 19.0.1, mas ainda estou tendo um problema. Também estou criando uma imagem Docker com --no-cache-dir que funciona bem com pip <19.0. Alguém mais está recebendo isso?

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

Fiquei animado para ver a nova correção da versão 19.0.1, mas ainda estou tendo um problema. Também estou criando uma imagem Docker com --no-cache-dir que funciona bem com pip <19.0. Alguém mais está recebendo isso?

A correção está funcionando para mim com 19.0.1 - Suspeito que você tenha um cache de camada do docker que está confundindo você? - tente pip --version para verificar em qual versão você está

Eu tenho uma verificação de versão Python e pip em todos os meus arquivos Docker, e ele relata 19.0.1 corretamente.

@dmulter Eu reconstruí minhas imagens do Docker em meu Gist do zero esta manhã e as coisas estão funcionando bem com v19.0.1 . Você pode compartilhar seu Dockerfile em um Gist também para que possamos vê-lo?

Limpei tudo de novo para ter certeza. Aqui está o Dockerfile e minha saída de compilação .

Veja minha nota sobre a saída da compilação para os comandos docker que foram usados.

Existe uma correção para o pip3? Aqui está o erro que recebi ...

> 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 Você tem um pequeno erro de digitação / sem um decimal. O lançamento do patch é 19.0.1 mas você tem 19.01 escrito.

opa meu erro, mas de qualquer forma, as versões possíveis não têm 19.0.1 listados ... ¯_ (ツ) _ / ¯

Como @dmulter , estou achando que o problema ainda não foi resolvido. Extrair da saída da compilação:

. 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 no tópico , perguntei se a inclusão de --no-use-pep517 junto com --no-cache-dir faz as coisas funcionarem para as pessoas, mas não vi uma resposta. Para pessoas que ainda estão experimentando a opção, você pode tentar?

Adicionar a opção --no-use-pep517 resolveu o problema para mim. Espero que ajude a restringir as coisas.

pip 19.0.1 trabalhando para mim em um virtualenv. Mas dentro do Jenkins (Shining Panda) ele ainda falha. Adicionar --no-use-pep517 corrige o problema

Estou reabrindo porque algumas pessoas ainda estão enfrentando o mesmo problema.

Também posso confirmar que --no-use-pep517 corrigiu o problema para mim depois de atualizar para o pip 19.0.1, não.

Mas por que todos esses projetos precisam se adaptar sempre que o pip obtém uma nova versão?

A pedido de @pradyunsg , abri uma nova edição (https://github.com/pypa/pip/issues/6197) específica para AssertionError na versão 19.0.1, pois é mais restrita no escopo e precisará de uma nova investigação. Portanto, estou encerrando esse problema.

Encontrou o mesmo problema. Acabou fixando a versão do pip como uma correção por enquanto.

pip install --upgrade pip==18.1

ou seu FROM python:3.6-alpine pode mudar para FROM python:3.6.7-alpine

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Abra um novo problema para bugs relacionados.