Pip: 19.0で--no-cache-dirを使用する場合のアサーション

同じことが起こっています：
Python v3.6.8
pip version 18.1
オン
Ubuntu:latest画像。

@snstantonどのベースイメージを使用していますか？ pipv18.1でも同様の問題が発生しています

まったく同じ問題があります。
私の側では、どのパッケージ/ディストリビューションをインストールしようとしても問題ではないようです

--no-cache-dir設定されていなくても、これが表示されます。 すでにインストールされている場合でも、インストールしようとしているすべてのパッケージで発生します。

• pipバージョン：19.0
• Pythonバージョン：3.6.0
• OS：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

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設定することで回避できます。

ただし、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

問題はassertの失敗にあるため、env PYTHONOPTIMIZE = 1（またはパラメーター-O）を設定すると、このエラーはなくなります。
ちょうどそれをテストしました。
この回避策は、Pythonがコードを最適化して、すべてのアサーションを削除するために機能します。
= 2（または-OO）を選択しないでください。これにより、docstringが削除され、他のトレースバックが表示されます。一部のコードはそれらを操作したいと考えています。

これが問題になる可能性があることを誰かが知っていたようです（ソース）：

        # 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 ：

更新：ここでアスペクションをキャストしようとはしていませんが、リリースがちょうど起こったので、これによって影響を受ける人々のブロックをすばやく解除する1つの方法として提案していました。 ホットフィックスを使用してロールフォワードすることもできます。 このミッションクリティカルなツールをサポートするコミュニティの努力に感謝し、間違いから学び、将来の問題を防ぐための事後分析に関する以下の感情に同意します。 その間、私たちは内部で同じことをしています。つまり、すべての場所でpipバージョンを自由に固定することを意味します:)

TODOコメントを追加するPRにも、このコメントが返信されています： https ：

そのコメントと、 PYTHONOPTIMIZE=1を渡すとエラーがなくなるという上記のコメントに基づくと、アサーションを削除するだけで正しい修正が行われる可能性があります（ロールバックの問題とは関係ありません）。

ええ、そのアサーションを削除すると、パッケージは--no-cache-dir正常にインストールされます。 その場合には、それは言うのRunning setup.py installの代わりにBuilding wheel sdistのパッケージ。

これは私のプロジェクトにも起こっています。 これは、Python 3をソースからインストールしているFROM ubuntu:bionicとFROM centos:centos7でビルドされたDockerイメージで再現できます（これは、これらの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維持者や貢献者を非難するべきではありません。

ただし、このバグは、一般リリースに入る前に発見された（逃した）機会の数が多いため、pipチームの側で何らかの事後分析を行う価値があることをお勧めします。 例えば：

• --no-cache-dirようなコア機能の自動テスト
• TODOフラグを立てる（または禁止する）事前コミット、事前マージ、または事前リリースチェック
• PR内のすべての未解決のレビューコメントの（人間の）マージ前レビュー（Githubは、関連付けられたコードが変更されたときにほとんどのレビューコメントスレッドを自動最小化し、最近では、レビューコメントスレッドを解決済みとして手動でマークできます）
• リリースプロセスの変更—最初にベータ版をリリースしてから、数週間待ってから一般リリースしてみませんか？
• 等

事後分析により、Pythonプロジェクトのコアであるpipと同じくらい重要なソフトウェアに、将来この規模のバグが含まれないようにするために、多くの役立つ改善がもたらされる可能性があります。

このバグを再現できます。 --no-cache-dirを削除すると、修正されます。 Dockerイメージに@ 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 ）オプションを使用すると、pipv19.0は何もインストールできません。

この問題のバグ修正として＃6171を提出しました。 このスレッドの人々はそのPRを試して、それが実際にこの問題を修正することを確認できますか？

PS：この問題を迅速に修正するために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固定しないという事実を見るのは賢明だと思います資産としてのいないことがよくあります。たとえば、私が働いている場所では、Python自体が通常は効果的にマイナーバージョンに固定されています。新しいパッチバージョンは自動的に取得されます。新しいビルドによって採用されました。これは、ユーザーがこれらのコアツールとその保守性に対して高いレベルの信頼を持っていることを示していると思います。）

このような事件はその信頼を損ないます。 壊れたCIビルドは実際の問題ではありません（あなたが言うように、CIビルドにpipを固定するか、何を危険にさらしているのかを知っておく必要があります）が、症状、またはむしろ相関する警告です。それは信頼を侵食しました。

そのため、この事件はある種の（非難のない）死後のプロセスに値すると提案しました。 pipメンテナは今のところ気分が悪いはずはありませんが、これは深刻な問題であり、改善のために調査する必要があります。

ええ、このような事件は信頼を築くのに役立ちません。 これらを回避する方法を見つけるために事後分析を行います（常に改善の余地があるため、リリースごとにそれを行います）。

（ほとんど）適切な談話を維持し、建設的なコメントをありがとう！ 通常、このような問題があると、物事は私たちにとってはるかに腐食性になります。 :)

それでもなお、調査すべきバグレポートが他にもいくつかあり、まもなく19.0.1になります。

ここで重要なことは、 --no-cache-dir下でビルドするための十分なテストがないことを明らかにしたことだと思います。 その領域での追加のテストは、このようなリグレッションを回避するのに非常に役立ちます。より一般的には、どの「主要な」機能が十分にテストされていないかを確認することが役立ちます。

ピップメンテナーとして、私が抱えている問題の1つは、人々が「重要な」機能と見なしているものを知ることだと思います。 個人的には、 --no-cache-dirはかなりニッチだと思っていたので、この場合、明らかに私の直感は信頼できません:-)したがって、このようなフィードバックは特に価値があります。

このバグのためだけに19.0.1ですぐにリリースできると思います。結局のところ、それは重要で緊急です。 別のバグレポートは、19.0.2で翌日解決できます。

ピップメンテナーとして、私が抱えている問題の1つは、人々が「重要な」機能と見なしているものを知ることだと思います。 個人的には、 --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

ピップメンテナーとして、私が抱えている問題の1つは、人々が「重要な」機能と見なしているものを知ることだと思います。 個人的には、-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で機能しています-混乱しているDockerレイヤーキャッシュがあると思いますか？ - pip --versionを試して、現在のバージョンを確認してください

すべてのDockerファイルにPythonとpipのバージョンチェックがあり、19.0.1が正しく報告されます。

@dmulter今朝、GistでDockerイメージv19.0.1ます。 DockerfileをGistで共有して、全員が確認できるようにすることはできますか？

念のため、すべてをもう一度掃除しました。 これがDockerfileと私のビルド出力です。

使用された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オプションを追加すると、問題が解決しました。 それが物事を絞り込むのに役立つことを願っています。

仮想環境で私のために働いているpip19.0.1。 しかし、Jenkins（Shining Panda）の内部ではまだ失敗しています。 --no-use-pep517を追加すると、問題が修正されます

一部の人々がまだ同じ問題を経験しているので、私は再開しています。

また、pip 19.0.1にアップグレードした後、 --no-use-pep517で問題が修正されたことを確認できます。

しかし、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変更できます

このスレッドは、閉じられた後に最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。