Pip: 19.0에서 --no-cache-dir을 사용할 때 어설 션

다음과 같은 일이 발생합니다.
Python v3.6.8
pip version 18.1
의 위에
Ubuntu:latest 이미지.

@snstanton 어떤 기본 이미지를 사용하고 있습니까? pip v18.1에서도 비슷한 문제가 발생합니다.

나는 똑같은 문제가 있습니다.
내 입장에서는 어떤 패키지 / 배포를 설치하려고하는지가 중요하지 않은 것 같습니다.

--no-cache-dir 설정하지 않아도 표시됩니다. 설치하려는 모든 패키지가 이미 설치되어 있어도 발생합니다.

• pip 버전 : 19.0
• Python 버전 : 3.6.0
• 운영체제 : Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-generic x86_64)

제 경우에는 sudo -H 및 bash -l -c 조합으로 sudo -H pip 를 실행할 때 표시됩니다.

$ 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 설정하여 해결할 수 있습니다.

그러나 이것은 virtualenv를 마지막으로 업그레이드 한 시간에 따라 매우 오래된 버전의 pip를 제공 할 수 있습니다.

이것은 또한 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)을 설정하면이 오류가 사라집니다.
방금 테스트했습니다.
이 해결 방법은 파이썬이 모든 어설 션을 제거하는 코드를 최적화하기 때문에 작동합니다.
= 2 (또는 -OO)로 가지 마십시오. 독 스트링을 제거하고 다른 트레이스 백이 나타날 것입니다. 일부 코드는 이에 대해 작동하려고합니다.

누군가 이것이 문제가 될 수 있다는 것을 알고있는 것 같습니다 ( 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 이것이 원인이 될 수있는 관련 변경 인 것 같습니까?

pip 유지 관리자가이 주요 변경 사항을 해결하기 위해 최근 19 릴리스를 롤백해야하는 것 같습니까?
19.0 릴리스 정보 : https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

업데이트 : 여기에서 욕설을 던지려고하지 않고 릴리스가 _just_ 발생했을 때이 영향을받는 사람들을 신속하게 차단 해제하는 한 가지 방법을 제안했습니다. 핫픽스로 롤 포워드하는 것도 작동합니다. 이 미션 크리티컬 도구를 지원하는 커뮤니티의 노고에 감사 드리며, 실수로부터 배우고 향후 문제를 예방하기위한 사후 분석에 대한 아래의 감정에 동의합니다. 한편, 우리는 내부적으로 동일한 작업을 수행하고 있습니다. 즉, 모든 위치에서 pip 버전을 자유롭게 고정 할 수 있습니다. :)

TODO 댓글을 추가 한 PR도 답장으로이 댓글이 있습니다 : https://github.com/pypa/pip/pull/5743/files#r215832743

해당 주석과 PYTHONOPTIMIZE=1 를 전달하면 오류가 사라진다는 위의 주석 작성자가 단언 문을 제거하는 것이 올바른 수정일 수 있습니다 (롤백 문제와 무관).

예, 그 주장을 삭제하면 패키지가 --no-cache-dir 잘 설치됩니다. 이 경우 sdist 패키지의 경우 Building wheel 대신 Running setup.py install 됩니다.

이것은 내 프로젝트에서도 일어나고 있습니다. 소스에서 Python 3을 설치하는 FROM ubuntu:bionic 및 FROM centos:centos7 빌드 된 Docker 이미지에서이를 재현 할 수 있습니다 (여기 에 해당 Docker 이미지 모두에 대해 실패한 예를 보여주는 Gist 가 있습니다. 도움이 될 수 있습니다). Gist의 예에서 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가 자동 업데이트되지 않도록하는 것입니다.

또한 이미지를 작게 유지하기 위해 Docker 내부 설치에 --no-cache-dir 가 있습니다. 해결 방법은 동일한 RUN 단계에서 --cache-dir=/pipcache 및 rm -rf /pipcache 를 사용하는 것이므로 이미지에서 끝나지 않습니다.

소프트웨어 개발은 ​​어렵고 이와 같은 버그는 항상 발생합니다. 확실히 아무도이 사건에 대해 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

단순히 어설 션을 제거하는 것이 올바른 수정일 수 있습니다.

정확히는 아닙니다. ephem이 아닌 빌드를 위해 이것을 유지해야한다고 생각합니다. 아침 식사가 끝나면 버그 수정 PR을 제출하겠습니다. :)

@pradyunsg 내 PR에서 실패한 테스트를 확인하십시오.

나를 위해 --no-cache (또는 --no-cache-dir ) 옵션을 사용하면 pip v19.0이 아무것도 설치하지 못합니다.

이 문제에 대한 버그 수정으로 # 6171을 제출했습니다. 이 스레드의 사람들이 PR을 시도하고 실제로이 문제를 해결하는지 확인할 수 있습니까?

추신 :이 문제를 신속하게 해결하기 위해 PR을 제출해 주신 @tgs 에게 감사드립니다! :)

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을 릴리스하기를 바랍니다.

사람들은 다른 패키지 또는 종속성, IMO에 대해 수행하는 것처럼 CI에 pip를 고정해야합니다. 그렇지 않으면 재현성이없고 갑작스러운 파손의 위험이 있습니다. 고정하면 미리 확인하고 원하는 속도로 업그레이드 할 수 있습니다.

사람들은 다른 패키지 또는 종속성, IMO에 대해 수행하는 것처럼 CI에 pip를 고정해야합니다. 그렇지 않으면 재현성이없고 갑작스러운 파손의 위험이 있습니다. 고정하면 미리 확인하고 원하는 속도로 업그레이드 할 수 있습니다.

@cjerdonek : pip 사용자 관점에서 볼 때 많은 (아마도 대부분의) 컨텍스트에서 pip 을 고정하는 것이 좋습니다. 최소한 고정하지 않으면 정확히 이런 종류의 위험을 감수하고 있다는 사실을 알아야하며, 이런 일이 발생하더라도 pip 관리자에게 불평 할 수 없습니다!

그러나 ... pip 관리자 관점에서 (그리고 더 광범위하게 PyPA 또는 Python 핵심 팀 관점에서) 많은 사람들이 pip 고정하지 않는다는 사실을 보는 것이 현명하다고 생각합니다. 자산으로 되지 않는 경우가 종종 있습니다. 새로운 빌드에 의해 선택되었습니다. 이것은 사용자가 이러한 핵심 도구와 유지 관리에 대한 신뢰 수준이 높아 졌음을 보여줍니다.)

이와 같은 사건은 그 신뢰를 약화시킵니다. 깨진 CI 빌드는 실제 문제가 아니지만 (당신이 말했듯이 CI 빌드에 pip 를 고정하거나 어떤 위험이 있는지 알고 있어야 함) 다음의 증상 또는 오히려 상관 된 경고입니다. 그로 인해 신뢰가 무너졌습니다.

이것이 제가이 사건이 일종의 (비난없는) 사후 분석 과정의 가치가 있다고 제안한 이유입니다. 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을 가질 것이라고 생각합니다.

다른 PEP 517 관련 문제인 https://github.com/pypa/pip 와 같이 --no-use-pep517 를 --no-cache-dir --no-use-pep517 와 함께 포함하는 것이이 문제에 대한 또 다른 해결 방법인지 궁금합니다. / issues / 6163 # issuecomment -456772043

핍 관리자로서 제가 가진 한 가지 문제는 사람들이 "핵심"기능을 고려하는 것을 아는 것입니다. 개인적으로, 나는 --no-cache-dir이 상당히 틈새 시장이라고 생각했을 것입니다. 그래서 분명히이 경우 제 직감은 신뢰할 수 없습니다. :-) 따라서 이와 같은 피드백은 특히 가치가 있습니다.

FWIW : Docker 이미지를 빌드 할 때 --no-cache-dir 자주 사용하여 유용하지 않은 환경에서 캐시 크랙이 남지 않도록합니다.

사람들은 다른 패키지 또는 종속성, IMO에 대해 수행하는 것처럼 CI에 pip를 고정해야합니다. 그렇지 않으면 재현성이없고 갑작스러운 파손의 위험이 있습니다. 고정하면 미리 확인하고 원하는 속도로 업그레이드 할 수 있습니다.

많은 환경에서 pip는 종속성이 아닙니다. virtualenv를 만들 때 설치됩니다.

그건 그렇고 제품이 최신 버전에서 작동하는지 확인하기 위해 거기에서 테스트하지 않습니다. 모든 것을 고정하면 이전 버전이 사용됩니다. 그리고 업데이트는 곧 누구도 감히 시작할 수없는 작업이 될 것입니다. 거기 있었어. 그래서 제 의견은 정말로 필요한 경우에만 고정하는 것입니다. 그리고 문제가 발생하는 즉시 수정하십시오.

pip 19.0.1은이 문제에 대한 수정으로 나왔습니다.

새로운 19.0.1 버전 수정을보고 기뻤지 만 여전히 문제가 있습니다. 또한 pip <19.0에서 잘 작동하는 --no-cache-dir 로 Docker 이미지를 만들고 있습니다. 이걸받는 다른 사람 있나요?

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 버전 수정을보고 기뻤지 만 여전히 문제가 있습니다. 또한 pip <19.0에서 잘 작동하는 --no-cache-dir 로 Docker 이미지를 만들고 있습니다. 이걸받는 다른 사람 있나요?

19.0.1에서 수정이 작동합니다. 혼란스러운 도커 레이어 캐시가 있다고 생각합니까? -현재 사용중인 버전을 확인하려면 pip --version 을 (를) 시도하십시오.

모든 Docker 파일에 Python 및 pip 버전 검사가 있으며 19.0.1이 올바르게보고됩니다.

@dmulter 오늘 아침 Gist 에서 내 Docker 이미지를 처음부터 다시 빌드했으며 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

이전 스레드에서 I는 다음과 같은 경우 물었다 --no-use-pep517 과 함께 --no-cache-dir 사람들을위한 일 작동 할 수있게,하지만 나는 답장을 보지 못했다. 여전히 옵션을 경험하는 사람들을 위해 시도해 볼 수 있습니까?

--no-use-pep517 옵션을 추가하면 문제가 해결되었습니다. 범위를 좁히는 데 도움이되는 희망.

pip 19.0.1은 virtualenv에서 나를 위해 일합니다. 그러나 Jenkins (Shining Panda) 내부에서는 여전히 실패합니다. --no-use-pep517을 추가하면 문제가 해결됩니다.

일부 사람들이 여전히 같은 문제를 겪고 있기 때문에 다시 시작합니다.

또한 --no-use-pep517 에서 pip 19.0.1로 업그레이드 한 후 문제가 해결되지 않았 음을 확인할 수 있습니다.

하지만 왜 모든 프로젝트가 pip가 새 버전을 얻을 때마다 적응해야합니까?

@pradyunsg 의 요청 에 따라 19.0.1 릴리스의 AssertionError 에 해당하는 새로운 문제 (https://github.com/pypa/pip/issues/6197)를 열었습니다. 범위에 있으며 새로운 조사가 필요합니다. 그래서 저는이 문제를 다시 닫고 있습니다.

같은 문제가 발생했습니다. 지금은 pip 버전을 수정으로 고정했습니다.

pip install --upgrade pip==18.1

또는 FROM python:3.6-alpine 이 FROM python:3.6.7-alpine 변경 될 수 있습니다.

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를여십시오.