Pip: утверждение при использовании --no-cache-dir в 19.0

То же самое происходит с:
Python v3.6.8
pip version 18.1
на
Ubuntu:latest изображение.

@snstanton какое базовое изображение вы используете? Я также вижу аналогичную проблему в pip v18.1

У меня точно такая же проблема.
с моей стороны, кажется, не имеет значения, какой пакет / дистрибутив я пытаюсь установить

Я вижу это даже без набора --no-cache-dir . Это происходит со всеми пакетами, которые я пытаюсь установить, даже если они уже установлены.

• версия пункта: 19.0
• Версия Python: 3.6.0
• ОС: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-generic x86_64)

Следует отметить, что в моем случае я вижу это при запуске pip с комбинацией sudo -H и 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

Выполняя те же команды без -l на моем bash -c или вообще без bash -l -c , все работает нормально.

$ 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

Интересно, что если я запустил ту же команду без участия sudo или bash , она все равно не сработает с той же ошибкой, поэтому кажется, что это какая-то странная проблема с разрешениями.

Другой обходной путь для некоторых ситуаций

Для людей, которые столкнулись с этой ошибкой, потому что virtualenv автоматически устанавливает последнюю версию pip, вы можете обойти ее, указав virtualenv параметр --no-download или установив VIRTUALENV_NO_DOWNLOAD=1 .

Но имейте в виду, что это может дать вам очень старую версию pip, в зависимости от того, когда вы в последний раз обновляли virtualenv.

Это также работает с tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

для чего это стоит: он также не работает с той же ошибкой, если пакет уже установлен:

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$

Попался в ту же проблему. Закончилось закреплением версии pip в качестве исправления на данный момент.

pip install --upgrade pip==18.1

Проблема связана с ошибкой утверждения, поэтому установка env PYTHONOPTIMIZE = 1 (или с параметром -O) устраняет эту ошибку.
Просто протестировал.
Этот обходной путь работает, потому что python оптимизирует код, удаляя все утверждения как одну из вещей.
Не используйте = 2 (или -OO), так как это удалит строки документации и появятся другие трассировки - какой-то код хочет с ними работать.

Похоже, кто-то знал, что это может стать проблемой ( источник ):

        # 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 похоже, что это связанное изменение, которое могло вызвать это?

Похоже, специалисты по обслуживанию пипса должны откатить последний выпуск 19, чтобы исправить это критическое изменение?
Примечания к выпуску 19.0: https://github.com/pypa/pip/blob/master/NEWS.rst#190-2019-01-22

ОБНОВЛЕНИЕ: здесь я не пытался клеветать, а просто предлагал как один из способов быстро разблокировать людей, пострадавших от этого, видя, что релиз только что произошел. Прокат вперед с исправлением тоже работает. Я ценю усердную работу сообщества, которое поддерживает этот критически важный инструмент, и согласен с приведенными ниже мнениями о вскрытии, чтобы учиться на ошибках и предотвращать проблемы в будущем. Между тем, мы делаем то же самое внутри, что означает большое количество жестких версий pip во всех местах :)

PR, добавляющий комментарий TODO, также имеет этот комментарий в ответе: https://github.com/pypa/pip/pull/5743/files#r215832743

На основании этого комментария, а также приведенного выше комментатора, говорящего, что передача PYTHONOPTIMIZE=1 устраняет ошибку, кажется, что простое удаление утверждения может быть правильным исправлением (независимо от вопроса об откате).

Да, когда я удаляю это утверждение, пакеты устанавливаются нормально с --no-cache-dir . В этом случае он говорит, что это Running setup.py install вместо Building wheel для пакетов sdist.

То же самое происходит и с моими проектами. Я могу воспроизвести это в образах Docker, созданных FROM ubuntu:bionic и FROM centos:centos7 где я устанавливаю Python 3 из исходного кода (вот Gist, который демонстрирует пример сбоя для обоих этих образов Docker в случае, если он может быть полезно). Для requirements.txt в примере в Основном и

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

тогда

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

терпит неудачу с

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

но

$ pip3 install --upgrade -r requirements.txt

работает нормально, как ожидалось.

Я особенно поражаю это с помощью tox + docker + ENV PIP_NO_CACHE_DIR=off

Мое обходное решение - использовать плагин tox-virtualenv-no-download чтобы предотвратить автоматическое обновление pip

У нас также есть --no-cache-dir в наших установках внутри Docker, чтобы изображения были небольшими. Нашим обходным путем было --cache-dir=/pipcache а затем rm -rf /pipcache в том же шаге RUN чтобы он никогда не попал в изображение.

Разработка программного обеспечения - это сложно, и подобные ошибки будут происходить всегда. Конечно, никто не должен винить в этом инциденте разработчиков или участников pip .

Тем не менее, я бы предположил, что эта ошибка заслуживает своего рода посмертного анализа со стороны команды pip из-за количества (упущенных) возможностей для обнаружения этой ошибки до того, как она попадет в общий выпуск. Например:

• автоматическое тестирование основных функций, например --no-cache-dir
• проверка перед фиксацией, предварительным слиянием или предварительным выпуском отметки (или запрета) TODO s
• (человеческий) предварительный просмотр всех неразрешенных комментариев обзора в PR (Github автоматизирует большинство цепочек комментариев обзора, когда их связанный код был изменен, и с недавнего времени позволяет вручную отмечать цепочки комментариев обзора как разрешенные)
• изменения в процессе выпуска - почему бы не выпустить сначала бета-версию, а затем подождать несколько недель до общего выпуска?
• и т.д

Вскрытие может привести к ряду полезных улучшений, чтобы гарантировать, что программное обеспечение, столь же важное для проекта Python, как pip не будет поставляться с ошибками такого масштаба в будущем.

Я могу воспроизвести эту ошибку. Удаление --no-cache-dir исправляет это. Поскольку мне это не нужно в моем образе докера, я использую предложенное решение @coderanger . Привет 🌈🍰🌈

Похоже, это дубликат выпуска № 6166.

Быстрое и удобное воспроизведение 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

простое удаление утверждения может быть правильным исправлением

Не совсем так - я думаю, нам стоит оставить это там для неэфемных сборок. Я запишу PR исправления, как только закончу с завтраком. :)

@pradyunsg проверь мой PR на предмет провала теста

Для меня pip v19.0 не сможет ничего установить, если используется опция --no-cache (или --no-cache-dir ).

Я зарегистрировал № 6171 как исправление этой проблемы. Могут ли люди из этой ветки попробовать этот PR и убедиться, что он действительно решает эту проблему?

PS: Спасибо @tgs за подачу PR, чтобы помочь быстро

wfm, спасибо за исправление!

$ 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

Надеюсь в ближайшее время объединить PR6171 и выпустить версию 19.0.1

Людям действительно стоит закрепить пип в CI, как вы бы сделали для любого другого пакета или зависимости, IMO. В противном случае у вас не будет воспроизводимости и риск внезапных поломок. Прикрепив, вы можете заранее проверить все и обновиться в удобном для вас темпе.

Людям действительно стоит закрепить пип в CI, как вы бы сделали для любого другого пакета или зависимости, IMO. В противном случае у вас не будет воспроизводимости и риск внезапных поломок. Прикрепив, вы можете заранее проверить все и обновиться в удобном для вас темпе.

@cjerdonek : Я согласен с вами в том, что - с точки зрения пользователя pip - неплохо закрепить pip во многих (возможно, в большинстве) контекстах. По крайней мере, если вы не приколите, вы должны знать, что рискуете именно такими вещами, и вы не можете жаловаться разработчикам pip если это произойдет!

Однако ... от pip разработчике перспективы (и в более широком плане с основной точки зрения команды PyPA или Python) Я думаю , что было бы целесообразно , чтобы посмотреть на то , что очень многие люди не штырь pip в качестве актива. Это нематериально, но демонстрирует большое доверие со стороны пользователей. (В стороне, возможно, парадоксально, по моему опыту. Часто бывает, что большинство основных инструментов не закреплены, как большинство зависимостей. Например, там, где я работаю, сам python обычно эффективно прикрепляется к младшей версии - новые версии патчей автоматически получают подхвачены новыми сборками. Я думаю, это показывает повышенный уровень доверия пользователей к этим основным инструментам и их поддержке.)

Подобные инциденты подрывают это доверие. Неисправные сборки CI не являются реальной проблемой (как вы говорите, вы должны либо закрепить pip в сборках CI, либо знать, чем вы рискуете), но являются симптомом - или, скорее, соответствующим предупреждением - это подорвало доверие.

Вот почему я предположил, что этот инцидент заслуживает какого-то (безупречного) вскрытия. Ни один pip сопровождающий сейчас не должен чувствовать себя плохо, но это серьезная проблема, и ее следует изучить для улучшения.

Да, подобные инциденты не помогают укрепить доверие. У нас будет вскрытие, чтобы выяснить, как этого избежать (мы делаем это после каждого выпуска, потому что всегда есть возможности для улучшения).

Спасибо (в основном) за правильное обсуждение и за конструктивные комментарии! Обычно, когда возникает такая проблема, для нас все гораздо более агрессивно. :)

Тем не менее, есть еще пара отчетов об ошибках, которые нужно изучить, и скоро у нас будет 19.0.1.

Я думаю, что ключевым моментом здесь является то, что это показало, что у нас нет достаточного количества тестов для сборки под --no-cache-dir . Дополнительные тесты в этой области были бы огромным подспорьем в предотвращении подобных регрессий, и, в более общем плане, было бы полезно проанализировать, какие «ключевые» функциональные возможности недостаточно протестированы.

Как сопровождающий пипса, я бы сказал, что у меня есть одна проблема - знать, что люди считают «ключевой» функциональностью. Лично я бы предположил, что --no-cache-dir был довольно нишевым, поэтому очевидно, что моя интуиция в этом случае ненадежна :-) Следовательно, такая обратная связь особенно ценна.

Думаю, что скоро может быть выпущена 19.0.1 только для этой ошибки, в конце концов, она существенная и срочная. Другие отчеты об ошибках могут решить в 19.0.2 на следующий день.

Как сопровождающий пипса, я бы сказал, что у меня есть одна проблема - знать, что люди считают «ключевой» функциональностью. Лично я бы предположил, что --no-cache-dir было довольно нишевым, поэтому очевидно, что моя интуиция в данном случае ненадежна :-) Следовательно, такая обратная связь особенно ценна.

Единственная причина, по которой я использую --no-cache-dir , - это установка mpi4py .
Таким образом, я могу обеспечить его повторную загрузку и пересборку перед установкой, убедившись, что все изменения, внесенные в мой дистрибутив MPI, приняты во внимание.

Та же проблема здесь, возможность воспроизвести ее за пределами нашей системы CI. В качестве обходного пути мы перешли на pip 18.1.0, и все работает:

pip install pip==18.1.0

Надеюсь и скоро обновлюсь.

Я использую:

pip install "pip!=19.0"

Надежда 19.1 исправлена ​​:)

Я подозреваю, что относительно скоро у нас будет 19.0.1 с исправлениями возникающих проблем.

Мне любопытно, если включение --no-use-pep517 вместе с --no-cache-dir - это еще один способ решения этой проблемы, как и для другой проблемы, связанной с PEP 517: https://github.com/pypa/pip / issues / 6163 # issuecomment -456772043

Как сопровождающий пипса, я бы сказал, что у меня есть одна проблема - знать, что люди считают «ключевой» функциональностью. Лично я бы предположил, что --no-cache-dir было довольно нишевым, поэтому очевидно, что моя интуиция в этом случае ненадежна :-) Следовательно, такая обратная связь особенно ценна.

FWIW: я довольно часто использую --no-cache-dir при создании образов Docker, чтобы предотвратить вероятность того, что какой-либо мусор в кеше останется в среде, где он не будет полезен.

Людям действительно стоит закрепить пип в CI, как вы бы сделали для любого другого пакета или зависимости, IMO. В противном случае у вас не будет воспроизводимости и риск внезапных поломок. Прикрепив, вы можете заранее проверить все и обновиться в удобном для вас темпе.

Во многих средах pip не является зависимостью. Он устанавливается при создании файла virtualenv.

И, кстати, там не тестируется, работает ли ваш продукт с самыми последними версиями. Закрепление всего лишь приводит к использованию старых версий. А обновление скоро станет задачей, которую никто не решается начинать. Был там, сделал это. Так что мое мнение - приколоть только в случае крайней необходимости. И постарайтесь устранить проблемы, как только они возникнут.

pip 19.0.1 отсутствует с исправлением этой проблемы.

Я был рад увидеть новое исправление версии 19.0.1, но проблема все еще оставалась. Я также создаю образ Docker с --no-cache-dir который отлично работает с pip <19.0. Кто-нибудь еще это понимает?

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

Я был рад увидеть новое исправление версии 19.0.1, но проблема все еще оставалась. Я также создаю образ Docker с --no-cache-dir который отлично работает с pip <19.0. Кто-нибудь еще это понимает?

fix работает у меня с 19.0.1 - я подозреваю, что у вас есть кеш уровня докеров, который вас смущает? - попробуйте pip --version чтобы проверить, какая у вас версия

У меня есть проверка версии Python и pip во всех моих файлах Docker, и она правильно сообщает 19.0.1.

@dmulter Сегодня утром я перестроил свои образы Docker в моем Gist с нуля, и там все работает нормально с v19.0.1 . Можете ли вы поделиться своим Dockerfile в Gist, чтобы мы все могли его рассмотреть?

Просто очистил все заново на всякий случай. Вот Dockerfile и мои результаты сборки .

См. Мою заметку о результатах сборки для использованных команд докера.

Есть ли исправление для pip3? Вот ошибка, которую я получил ...

> 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 У вас есть небольшая опечатка / отсутствует десятичный разделитель. Релиз патча - 19.0.1 но у вас написано 19.01 .

К сожалению, моя ошибка, но в любом случае в возможных версиях нет 19.0.1 списке ... ¯_ (ツ) _ / ¯

Как и @dmulter, я считаю, что проблема все еще не

. 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

Ранее в этой ветке я спрашивал, помогает ли включение --no-use-pep517 вместе с --no-cache-dir , но я не нашел ответа. Можете ли вы попробовать это для людей, которые все еще испытывают такую ​​возможность?

Добавление опции --no-use-pep517 устранило проблему для меня. Надеюсь, что это поможет сузить круг вопросов.

pip 19.0.1 работает у меня в virtualenv. Но внутри Дженкинса (Сияющая панда) это все равно не удается. Добавление --no-use-pep517 устраняет проблему

Я открываюсь снова, потому что некоторые люди все еще сталкиваются с той же проблемой.

Я также могу подтвердить, что --no-use-pep517 устранил проблему для меня после обновления до 19.0.1.

Но почему все эти проекты должны адаптироваться, когда pip получает новую версию?

По запросу @pradyunsg я открыл новую проблему (https://github.com/pypa/pip/issues/6197), относящуюся к AssertionError в версии 19.0.1, поскольку она уже по объему и потребует нового расследования. Итак, я закрываю этот вопрос.

Попался в ту же проблему. Закончилось закреплением версии pip в качестве исправления на данный момент.

pip install --upgrade pip==18.1

или ваш FROM python:3.6-alpine может измениться на FROM python:3.6.7-alpine

Этот поток был автоматически заблокирован, поскольку после его закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему для связанных ошибок.