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）

我应该注意，在我的情况下，运行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

在我的bash -c -l上运行相同的命令而没有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看起来这是一个可能引起此问题的相关更改？

似乎pip维护者应该回滚最近的19版本以解决这一重大更改？
19.0发行说明： https :

更新：这里不打算散布垃圾，只是建议作为一种释放方式来快速解除对受此影响的人的阻止，因为发布已发生。 也可以使用修补程序前滚。 我感谢支持此关键任务工具的社区的辛勤工作，并同意以下关于验尸的观点，以从错误中学习并防止将来出现问题。 同时，我们在内部也做同样的事情，这意味着在所有地方都需要大量固定pip版本：)

添加TODO注释的PR也有以下注释： https :

根据该评论以及上面的评论者所说，传递PYTHONOPTIMIZE=1可以使错误消失，似乎简单地删除断言可能是正确的解决方案（与回滚的问题无关）。

是的，当我删除该断言时，软件包确实可以使用--no-cache-dir进行安装。 在那种情况下，它说它是Running setup.py install而不是sdist软件包的Building wheel 。

我的项目也正在发生这种情况。 我可以在构建FROM ubuntu:bionic和FROM centos:centos7 Docker映像中重现该代码，在这里我从源代码安装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自动更新

我们在Docker中的安装中也有--no-cache-dir ，以保持映像较小。 我们的解决方法是在同一RUN步骤中先执行--cache-dir=/pipcache ，然后执行rm -rf /pipcache ，这样它永远不会出现在图像中。

软件开发是艰巨的，并且这样的错误总是会发生。 当然，没有人应该为此事件责怪pip维护者或贡献者。

但是，我建议此bug值得点子团队进行事后分析，因为在进入通用发布之前已经发现了此bug的（丢失）机会很多。 例如：

• 自动测试核心功能，例如--no-cache-dir
• 提交（或禁止） TODO s的预提交，合并或发布前检查
• PR中所有未解决的评论注释的（人工）合并前评论（Github会在更改关联代码后自动最小化大多数评论注释线程，从最近开始，您可以手动将评论注释线程标记为已解决）
• 发行过程中的更改-为什么不先发行Beta，然后等待几周后再进行一般发行？
• 等等

验尸可能会带来许多有益的改进，以确保与pip一样作为Python项目核心的软件将来不会附带如此大的错误。

我可以复制此错误。 删除--no-cache-dir可修复该问题。 由于我不想在我的docker映像中使用它，因此我使用了建议的

这看起来像是第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是否通过了测试

对我来说，如果使用--no-cache （或--no-cache-dir ）选项，pip v19.0将无法安装任何东西。

我已将＃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版

人们真的应该像在其他任何软件包或依赖项中一样，在IMO中固定CI。 否则，您将没有可复制性，并且可能会突然断裂。 通过固定，您可以提前检查并按照自己的进度进行升级。

人们真的应该像在其他任何软件包或依赖项中一样，在IMO中固定CI。 否则，您将没有可复制性，并且可能会突然断裂。 通过固定，您可以提前检查并按照自己的进度进行升级。

@cjerdonek ：我同意您的观点-从pip用户的角度来看，在许多（也许是大多数）上下文中固定pip是个好主意。 至少，如果您不固定，您应该知道自己正冒这种风险，如果发生这种情况，您就不能向pip维护者抱怨！

但是...从pip维护者的角度（更广泛地从PyPA或Python核心团队的角度），我认为谨慎的观点是很多人不固定pip作为资产。 它是无形的，但显示出用户群的高度信任。 （顺便说一句，根据我的经验，也许反直觉通常不会像大多数依赖项

这样的事件削弱了这种信任。 损坏的CI构建不是实际的问题（如您所说，您应该将pip在CI构建中，或者要意识到自己要冒什么风险），但这是一个症状-或更确切地说是相关警告那削弱了信任。

这就是为什么我建议此事件值得某种（无罪的）验尸程序。 没有pip维护者现在应该会感到不舒服，但是，这是一个严重的问题，应该进行检查以寻求改善。

是的，此类事件无助于建立信任。 我们将进行验尸，以弄清楚如何避免这些情况（每次发布后都这样做，因为总有改进的余地）。

感谢（主要是）保持适当的论述和建设性的意见。 通常，当出现这样的问题时，事情对我们来说更具腐蚀性。 :)

尽管如此，还有一些其他的错误报告需要研究，我们很快就会有一个19.0.1。

我认为这里的关键是，这表明我们没有足够的测试来构建--no-cache-dir 。 在该领域中进行额外的测试将对避免此类回归提供巨大的帮助，并且更普遍地，对未充分测试哪些“关键”功能进行回顾将很有帮助。

作为一个pip维护者，我要说的一个问题是知道人们对“关键”功能的看法。 我个人认为--no-cache-dir相当小众，所以显然我的直觉在这种情况下不可靠:-)因此，这样的反馈特别有价值。

我认为，仅针对此错误，它才能很快发布19.0.1，毕竟这是重要而紧迫的。 另一个错误报告可以在19.0.2之后解决。

作为一个pip维护者，我要说的一个问题是知道人们对“关键”功能的看法。 我个人认为--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 --no-use-pep517一起包含是此问题的另一个解决方法，因为它是另一个与PEP 517相关的问题： https :

作为一个pip维护者，我要说的一个问题是知道人们对“关键”功能的看法。 就我个人而言，我会假设--no-cache-dir相当小众，因此显然我的直觉在这种情况下不可靠:-)因此，这样的反馈特别有价值。

FWIW：在构建Docker映像时，我经常使用--no-cache-dir ，以防止任何缓存碎片在无用的环境中留下的机会。

人们真的应该像在其他任何软件包或依赖项中一样，在IMO中固定CI。 否则，您将没有可复制性，并且可能会突然断裂。 通过固定，您可以提前检查并按照自己的进度进行升级。

在许多环境中，pip不是依赖项。 它是在创建virtualenv时安装的。

顺便说一句，这里没有进行测试以查看您的产品是否适用于最新版本。 固定所有内容只会导致使用旧版本。 并且更新将很快成为没人敢开始的任务。 去过也做过。 因此，我的观点是仅在确实必要时才固定。 并尝试尽快解决问题。

pip 19.0.1已解决此问题。

我很高兴看到新的19.0.1版本修复程序，但仍然有问题。 我还在用--no-cache-dir创建一个Docker镜像，可以在<19.0的pip下正常工作。 有人得到这个吗？

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版本修复程序，但仍然有问题。 我还在用--no-cache-dir创建一个Docker镜像，可以在<19.0的pip下正常工作。 有人得到这个吗？

修复适用于19.0.1的版本-我怀疑您有使您感到困惑的docker层缓存吗？ -尝试pip --version检查您使用的版本

我在所有Docker文件中都有一个Python和pip版本签入，它正确报告了19.0.1。

@dmulter我今天早上从零开始在Gist中重建了Docker映像v19.0.1在那里一切正常。 您是否也可以在Gist中共享您的Dockerfile，以便我们大家一起看看？

只是为了确定再次清洗了所有东西。 这是Dockerfile和我的build输出。

请参阅关于构建输出的注释，以了解所使用的docker命令。

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中为我工作。 但是在詹金斯（Shining Panda）内部，它仍然失败。 添加--no-use-pep517可解决此问题

我正在重新开放，因为有些人仍然遇到同样的问题。

我还可以确认--no-use-pep517在升级到点19.0.1后为我解决了该问题。

但是，为什么只要pip获得新版本，所有这些项目都必须适应？

应@pradyunsg的要求，我打开了一个新发行版（https://github.com/pypa/pip/issues/6197），该发行版特定于19.0.1版本中的AssertionError ，因为它的范围较窄范围，将需要进行新的调查。 所以我要重提这个问题。

遇到同样的问题。 最终将pip版本固定为现在的修复程序。

pip install --upgrade pip==18.1

或者您的FROM python:3.6-alpine可以更改为FROM python:3.6.7-alpine

该线程已被自动锁定，因为它关闭后没有任何近期活动。 请为相关错误打开新一期。