CI やローカルで長く使ってきた pip install --no-use-pep517 ... が、ある日から依存を1つも入れないまま次のエラーで止まることがあります。
Usage:
/usr/local/bin/python -m pip install [options] <requirement specifier> [package-index-options] ...
...
no such option: --no-use-pep517終了コードは 2 です。パッケージの解決やダウンロードに入る前、コマンドラインの解析の段階で止まります。
原因は、pip 25.3 で --no-use-pep517 オプションが削除されたことです。このフラグは、PEP 517 のビルドバックエンドを使わず、古い setup.py ベースのビルド経路を強制するためのものでした。pip 25.3 はその古い経路自体を削除して PEP 517 を常時有効にしたので、対応するフラグも無くなりました。直し方は、そのフラグを外すことです。
# --no-use-pep517 を外して、同じ install を実行する
pip install -r requirements.txtなぜ pip 25.3 以降で出るのか
境界は pip の版で、Python の版でもプロジェクトの内容でもありません。同じ --no-use-pep517 付きのコマンドを、pip 25.2 までは受理し、25.3 以降は「そんなオプションは無い」と拒否します。
| pip | --no-use-pep517 付き install の挙動 |
|---|---|
| 24.3.1 / 25.0 / 25.1 / 25.2 | 受理される（終了コード 0） |
| 25.3 / 26.0 以降 | no such option: --no-use-pep517（終了コード 2） |
そのため、次のような食い違いで表面化します。
- CI やコンテナで pip が新しく入った／更新された：クリーンな環境を作ると、そのとき入手できる新しい pip が入ります。手元の古い環境（pip 25.2 以下）では通り、CI だけが 25.3 以降で
no such optionになります。python -m pip install --upgrade pipを挟むワークフローでも、更新後に 25.3 を越えると同じ状態になります。 - 古い CI 設定を新しいベースイメージで動かした：
--no-use-pep517は、数年前にビルドバックエンド絡みの問題を回避するために足されたまま残っていることが多いフラグです。ベースイメージの pip が上がった拍子に、その延命フラグが失効します。
まず python -m pip --version で版を確認します。25.3 以降なら、この記事の削除に当たっています。
なぜ --no-use-pep517 が消えたのか
PEP 517 は、パッケージのビルド方法を pyproject.toml の [build-system] で宣言する仕組みです。それ以前は、pip が各パッケージの setup.py を直接呼んでビルドしていました（レガシー経路）。移行期には、PEP 517 のビルドで問題が出たときに古い経路へ戻すための --no-use-pep517 が用意されていました。
pip はこのレガシー経路を段階的に縮小し、pip 25.3 で setup.py を直接呼ぶビルド経路を削除しました。PEP 517 が唯一のビルド方式になったので、「PEP 517 を使わない」という指定は意味を持たなくなり、オプションごと削除されました。エラーが no such option（解析段階での拒否）なのは、フラグが無効になったのではなく、pip の語彙から消えたからです。
この形は、setuptools が setup.py test を削除して python setup.py test が通らなくなった error: invalid command ‘test’ の直し方 と同じで、**「昔の CI 手順が、新しいツールで語彙ごと消える」**タイプです。入れ直しや再実行では戻りません。
直し方：フラグを外す
--no-use-pep517 を外して、同じ install をそのまま実行します。pip をダウングレードする必要はありません。
pip install -r requirements.txtwheel が配られているパッケージは、pip がその wheel を入れるのでビルド経路の指定は関係せず、フラグを外すだけで入ります（今回の idna==3.10 がこれです）。ソースからビルドが必要なパッケージは、PEP 517 のバックエンド（pyproject.toml の [build-system]、宣言が無ければ既定の setuptools）でビルドされます。この経路が通るかは対象パッケージと環境によるので、フラグを外して別のビルドエラーが出た場合は、そのパッケージごとに対処します（次節）。
CI の設定ファイルや Dockerfile、Makefile に --no-use-pep517 が書いてあるなら、その箇所を削ります。フラグは1つ消すだけで、install する対象（requirements.txt の中身）は変えません。
切り分け（うまくいかないとき）
- フラグを外したら、今度はビルドで別のエラーが出る：もともと
--no-use-pep517を付けていたのは、PEP 517 ビルドで何か問題が起きるのを避けるためだった可能性があります。その問題が今表面化しているので、ビルドエラーの中身を読みます。C 拡張のコンパイルに失敗しているなら Failed building wheel の直し方（コンパイラや開発ヘッダが無い） が該当します。ビルドバックエンドの宣言（pyproject.tomlの[build-system]）が壊れている場合は、そのパッケージ側の問題です。 --use-pep517は残っているのに--no-側だけ無い：--use-pep517（PEP 517 を使う、という肯定側）は既定の挙動を明示するだけなので残っています。削除されたのは、レガシー経路へ戻す--no-use-pep517の側だけです。肯定側を書いていた CI はそのまま動きます。--use-deprecated=legacy-resolverを付けている別の CI がある：これは依存リゾルバの延命フラグで、--no-use-pep517とは別物です（別途 probe した範囲では pip 26.1.2 まで受理されました）。混同しないようにします。- 手元では通るのに CI でだけ落ちる：pip の版が違います。CI のログで実際に使われた pip の版を確認します。25.3 以降なら本記事の削除です。
- 古い pip に固定して回避したい：
pip install "pip<25.3"で 25.2 以下に留めれば--no-use-pep517は受理されますが、これは削除前の版に張り付く延命で、いずれベースイメージやツールの都合で越えることになります。レガシー経路自体が無くなった以上、フラグを外すのが後を引きません。フラグを外して別のビルド問題が出る場合だけ、その問題を解いてからにします。
検証環境
python:3.12-slim、ネットワーク有り、pip==25.3- 再現：
pip install --no-use-pep517 -r requirements.txt（idna==3.10）を実行すると、no such option: --no-use-pep517を出して終了コード 2 - 修正：
--no-use-pep517を外して同じrequirements.txtを install すると、終了コード 0・シグネチャ消滅（idna==3.10が入る）
再現から修正までは errfix の検証ハーネスが機械的に確認しています。reproduce と fix の差は --no-use-pep517 を付けるかどうかだけで、install 対象は同一です。版境界は、同じフラグ付きコマンドを pip==25.2 までは終了コード 0 で受理し、pip==25.3 以降は no such option で終了コード 2 になることを実測して裏づけました（24.3.1 / 25.0 / 25.1 / 25.2 で受理、25.3 / 26.0 / 26.1.2 で削除）。各版・終了コードはケースの verification/probes.txt に記録しています。