pipは2008年にIan BickingがEasyInstallの後継として開発を始めたPython向けパッケージ管理コマンドで、2011年のPython 3.4以降は標準ディストリビューションに同梱されるようになった。PyPI(Python Package Index)からwheelやsdistを取得し、依存ツリーを解決して環境へインストールする役目を担う。本稿ではpipの内部動作、よく使うサブコマンド、PEP 517/518以降の位置付け、運用上の注意点を順を追って整理する。
この記事の目次
- pipが解決する具体的な課題
- サブコマンドとオプションの実用例
- PEP 517/518以降のビルド責務の分離
- 運用で踏みやすい落とし穴
- まとめ
pipが解決する具体的な課題
pipの最大の役割は、PyPIに登録された数十万件のディストリビューションから必要な版を取り寄せ、Pythonインタプリタが解釈できる場所へ確実に配置することにある。2008年の初期実装ではEasyInstallの.egg形式を踏襲していたが、2012年のwheel(PEP 427)登場以降はバイナリ配布が主流となり、Cコンパイラを持たない利用者でもNumPyやSciPyを秒単位で導入できるようになった。pipはこのwheelの取得、検証、展開を担当し、site-packages配下に正規化された形でファイルを置く。
依存解決の側面では2020年12月リリースのpip 20.3で導入された新リゾルバが転機となった。それまでのpipは要求順に上書きインストールするだけで、矛盾する制約があっても警告すら出さないことがあった。新リゾルバはバックトラックを行い、互いに衝突するバージョン制約を検出して中断する。結果としてビルド失敗時のメッセージは長く複雑になったが、本番デプロイ時の壊れた組み合わせは大幅に減った。
サブコマンドとオプションの実用例
pip installは最頻出のコマンドだが、--no-binary, --only-binary, --prefer-binaryといったオプションを使い分けるとビルド時間とポータビリティのバランスを細かく調整できる。たとえばAlpine Linux系のコンテナではmusl libc向けwheelが少ないため--no-binary :all:でソースビルドを強制する一方、CIで毎回ビルドするのは無駄なので--prefer-binaryでwheelを優先取得するといった使い分けが現実的だ。pip --use-feature=fast-deps はメタデータのみの先行解決で、巨大プロジェクトの解決時間を数倍短縮する。
pip freezeとpip listは似て非なるコマンドで、freezeは=で固定したrequirements.txt形式、listはJSONや表形式での閲覧用に整形される。ただしpip freezeは編集可能インストール(pip install -e .)や、setuptoolsで作られた古いパッケージでメタデータが欠落している場合に正しい出力を返さないことがあり、これがpip-toolsやPoetryが生まれた背景の一つでもある。pip check は requires との不整合を見つけるが、optional dependenciesは検査しないため過信は禁物である。
PEP 517/518以降のビルド責務の分離
2018年のPEP 517と2016年のPEP 518により、Pythonパッケージのビルド責務はpipと「ビルドバックエンド」に明確に分離された。pipはfrontendとしてpyproject.tomlを読み、build-system.requiresに書かれたsetuptoolsやhatchlingを孤立環境に取り寄せ、そのbackendが提供するbuild_wheelフックを呼び出す。この設計のおかげで、setuptools以外のflit_core, hatchling, poetry-core, scikit-build-core等の多様なbackendが並列に発展できた。
歴史的にはsetuptoolsのsetup.pyが事実上の標準だったが、pyproject.toml中心の宣言的設定が広まったのは2019年以降である。pip 21.3でsetup.pyベースの非PEP 517プロジェクトもin-tree backendとして扱うようになり、pip 23.1ではeditable installがPEP 660準拠となり、site-packagesに.pthファイルを置く旧来の挙動から脱却した。つまりpipは年々「直接ビルドする道具」から「規約に沿ってbackendを呼び出す調停者」へと役割を変えてきている。
運用で踏みやすい落とし穴
pipはシンプルに見えて運用時の落とし穴が多い。代表的なものがシステムPythonへのグローバルインストールで、Debian系ではsudo pip installがOSパッケージ管理(apt)と衝突し、起動できなくなる事例が頻発した。Python 3.11以降のPEP 668ではexternally-managed-environmentマーカーが導入され、OS提供のPythonへの直接インストールはデフォルトで拒否されるようになっている。venvやpipxを介すのが正しい運用となる。
本番運用ではPyPIの可用性そのものもリスクであり、2022年4月の障害ではビルドパイプラインが全世界で停止した経験を持つ組織もある。対策としてdevpiやJFrog Artifactory、Sonatype Nexus等でPyPIをミラーし、内部インデックスを--index-urlで参照させる構成が一般的だ。またpip install時のハッシュチェック(--require-hashes)はサプライチェーン攻撃への基本的な防御策であり、pip-toolsやuvが生成するハッシュ付きrequirementsをそのまま使うのが推奨される。
まとめ
pipは2008年の登場以来、単なるインストーラから「PEP 517 frontend」「依存リゾルバ」「サプライチェーンの入口」へと役割を広げてきた。新リゾルバ、PEP 668、ハッシュ検証など近年の変更点を理解し、venvやpip-tools, uvといった周辺ツールと組み合わせて使うことで、再現性が高くセキュアなPython環境を構築できる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント