ローカルのソースアーカイブでもネットワークアクセスが必要になることがあります。pip がインストールする前に、wheel を作るためのビルドバックエンドと補助パッケージが必要になる場合があります。

失敗の位置をこの順序で特定します。対象アーカイブの取得、ビルド要件のインストール、バックエンドの実行、そして生成されたパッケージのインストールです。バックエンドのフックが追加のビルド要件を要求することがあり、これはパッケージの実行時依存関係とは別です。

pip がまだ必要とするアーティファクトを特定する

「Installing build dependencies」で、失敗したパッケージと URL を記録します。有効なインデックス、プロキシ経由の経路、アカウントの文脈、その要求に対する信頼を、インストール済み pip バージョンの文書化された設定を使って確認します。以前のダウンロードが成功したからといって、すべてのホストや各ヘルパーの環境へのアクセスが確立されるわけではありません。公開ビルド要件は、その経路が許可されている場合に HTTP プロキシ一覧 の HTTP 候補を使えます。必要なインデックスと信頼ポリシーは維持してください。従来の setup.py を使ったダウンロード手順は、異なるサブプロセスを使うことがあります。

別のマシンでインストールが成功する場合は、まず選択されたアーティファクトを比較します。その Python のバージョンやプラットフォームには互換性のあるビルド済み wheel があるかもしれませんが、このマシンはソース配布物を選んだためビルドツールが必要です。

ビルド環境を意図的に用意する

--no-build-isolation は、必要なビルド依存関係の責任をあなたに移します。プロキシ認証や証明書の信頼を修復するものではありません。ローカルにインストールされたバックエンドは、欠落した、あるいは互換性のない要件を隠すことがあります。

意図的にオフラインでビルドする場合は、承認された手順で、プロジェクトとプラットフォームに必要な対象アーティファクト、ビルド要件、ツールを用意します。ソースアーカイブだけを含むディレクトリは不完全です。失敗した要件と段階を報告に残し、経路または用意したアーティファクト一式のどちらかを修正できるようにしてください。

関連記事