パッケージとしてインストールすることを想定していないプロジェクトで依存関係をどのように扱うかは、Pythonとpipを使用する上で最大の不満の一つでした。

アプリケーションのバックエンド、Pythonスクリプト、REST APIなどのプロジェクトを考えてみてください。

もしこれに苦労したことがあるなら、気に入るでしょう：Sebastian Höffner氏によるPR #13895 が、pyproject.toml内の依存関係をパッケージ自体をインストールせずに直接インストールできる新しいグローバルフラグをpipに追加します。

pip install --only-deps .

これは少なくとも私にとって、サーバー上でプロジェクトを管理・配布する方法に大きな改善をもたらします。何年もかけて積み重なった手作業の回避策を大幅に簡素化します。

10年以上もかかったことなので、自身のスクリプトやアプリの依存関係をインストールする方法に苦労してきたPython開発者たちの歴史を振り返ってみましょう。

Requirements.txt？

python -m pip freeze [options]

Pip freezeは、インストールされているパッケージのバージョンを正確なバージョン番号まで記録し、再現性を確保するための古典的で確実な第一歩です。

これで任意の環境を再現できます！

env1/bin/python -m pip freeze > requirements.txt
env2/bin/python -m pip install -r requirements.txt

Pip freezeは（依存関係の依存関係を含む）すべての依存関係をエクスポートする

これらの依存関係は環境やハードウェアに固有のもので、他のマシンで環境を再現する際にはすぐに破綻します。異なるPythonバージョン、OSバージョン、ライブラリ、またはマシンのハードウェアにより、パッケージバージョンの要件（およびパッケージ全体）が異なる場合があります。

==を切り取る

これは私が最も古く記憶している問題の回避策で、必ずしも最善ではありませんでしたが、15年前に必要だったときにこれを残していたことをはっきりと覚えています：
pip freeze --local | grep -v '^\-e' | cut -d = -f 1

私やおそらくもっと以前の他の人々にとって、これは時折、requirements.txtに依存関係のリストを手動で追加するだけの方法に変化しました。これはかなり良い近道だったと思います。

pip install -e .

このコマンドはPipの全期間（2008年）を通じて正しく動作しており、pipに依存関係のリストをインストールさせる最速の方法です。これらは歴史的にpip以前から存在したPythonのsetup.py（その他）で見つかりました。依存関係は以来pyproject.tomlに移行しました。

しかしpip install -e .はパッケージ自体をインストールする

これはライブラリや一部のプロジェクトにはうまく機能しますが、Pythonコードを実行するラッパーを持つ可能性があるアプリケーション/APIフレームワークでは頭痛の種になります。

編集可能インストールはデプロイメントのベストプラクティスでもありません

パッケージとしてインストールすると2021年までディストリビューションベースのeggファイルが作成され、注意しないと古くなってしまいます。

16年間の人々が回避策を探し続けた歴史

私を含む人々は、依存関係をインストールする方法を何十年もStackOverflowで尋ねてきました：

PIP: Installing only the dependencies (16年前) -> pip install -e .を使用

pip freeze without dependencies of installed packages (15年前) -> サードパーティパッケージpip-chillを使用

pip freeze without dependencies of installed packages (10年前) -> サードパーティパッケージpipreqsを使用

Is there a smarter way to build requirements.txt files? (2年前) -> サードパーティパッケージpoetryまたはhatchを使用

Installing dependencies without the package (1年前) -> サードパーティパッケージuvを使用

これらのStackOverflow、Reddit、Python.orgの議論の流れを見てください。何年にもわたってこのような投稿が数百件ありますが、順に読んでいくと、サードパーティライブラリがより有用なソリューションにますます焦点を当てていたことがわかります。

基盤の構築：Pyproject.tomlと依存関係

Pyproject.tomlの導入後、2017年のPEP 517がpip、hatch、または後のuvなどの[build-system]のためのPyprojectフックを追加しました。

最終的な解決策で使用されるもう一つの重要な要素は、2023年のPEP 735 (Dependency Groups)で、devなどの依存関係のタイプをグループ化するためにPyproject.tomlに導入され、ユーザーが特定のインストールに必要な依存関係のグループを選択できるようにしました。

パーティクラッシャー：UV

最後に、Pythonエコシステムの愛され者であるuvにたどり着きます。これは非常に有用であることを示し、以前は停滞していたPython/Pipの変更の多くを促した可能性があります。上述の投稿では、多くの異なるユースケースのために使用されたビルドツールの繰り返しがありましたが、uvが達成した人気に到達したものはありませんでした。

uvの解決策：uv sync --no-install-project

UVはシーンに登場し、以前に築かれたすべての基盤を活用し、高速でユーザーフェイシングのCLIがユーザーの現実世界の問題を解決するビルドツールに対する潜在的な需要がどれほど大きかったかを示しました。

Pip：GitHub Issueが定着

提案された解決策

pip install --only-deps .  # project.dependencies
pip install --only-deps .[doc]  # project.dependencies and project.optional-dependencies

Höffner氏のプルリクエストは、プロジェクト自体をインストールせずにpyproject.tomlに基づいてプロジェクトの依存関係をインストールするグローバルオプションを追加します。Pip誕生からほぼ20年を経て、アプリケーションスタイルのプロジェクトやスクリプトの依存関係をインストールする機能がようやく実現しました。

2026年 コミュニティの努力によって生まれたエレガントな解決策

これに至る10年間の作業を振り返ると、PythonコミュニティのPEPs、pipのメンテナー、そしてサードパーティパッケージによって、多くのステップが必要でした。しかし今、私たちはここにいて、Pythonのpip 26.2に小さなしかし高品質な生活の質の向上が到来します。

私と同じくらい皆さんがこれを楽しんでいただけることを願っています。