pip tools
7.4.1
pipベースのパッケージを固定した場合でも、パッケージを最新の状態に保つのに役立つ一連のコマンド ライン ツール。ピン留めしますよね？ (実稼働用に Python アプリケーションとその依存関係を構築する場合、ビルドが予測可能で決定的であることを確認する必要があります。)
pipと同様に、 pip-toolsプロジェクトの各仮想環境にインストールする必要があります。
$ source /path/to/venv/bin/activate
(venv) $ python -m pip install pip-tools注: 残りのコマンド例はすべて、プロジェクトの仮想環境がアクティブ化されていることを前提としています。
pip-compileの使用例pip-compileコマンドを使用すると、 pyproject.toml 、 setup.cfg 、 setup.py 、またはrequirements.inのいずれかで指定された依存関係からrequirements.txtファイルをコンパイルできます。
pip-compileまたはpython -m piptools compileを使用して実行します (または、 pipx適切な Python バージョンでインストールされている場合はpipx run --spec pip-tools pip-compile使用します)。複数の Python バージョンを使用する場合は、Windows ではpy -XY -m piptools compile実行し、他のシステムではpythonX.Y -m piptools compile実行することもできます。
pip-compileプロジェクトと同じ仮想環境から実行する必要があります。これにより、特定の Python バージョンまたは他の環境マーカーを必要とする条件付き依存関係がプロジェクトの環境に応じて解決されます。
注: pip-compile依存関係を満たす既存のrequirements.txtファイルを見つけた場合、更新が利用可能であっても変更は行われません。最初からコンパイルするには、まず既存のrequirements.txtファイルを削除するか、代替アプローチの要件の更新を参照してください。
pyproject.tomlの要件pyproject.tomlファイルは、パッケージとアプリケーションを構成するための最新の標準であり、新しいプロジェクトに推奨されます。 pip-compile project.dependenciesとproject.optional-dependenciesの両方のインストールをサポートします。これが公式の標準であるという事実のおかげで、 pip-compile使用して、Setuptools、Hatch、flit などの最新の標準に準拠したパッケージ化ツールを使用するプロジェクトの依存関係を固定することができます。
Setuptoolsを使用してパッケージ化された 'foobar' Python アプリケーションがあり、それを運用環境に固定したいとします。プロジェクトのメタデータは次のように宣言できます。
[ build-system ]
requires = [ " setuptools " , " setuptools-scm " ]
build-backend = " setuptools.build_meta "
[ project ]
requires-python = " >=3.9 "
name = " foobar "
dynamic = [ " dependencies " , " optional-dependencies " ]
[ tool . setuptools . dynamic ]
dependencies = { file = [ " requirements.in " ] }
optional-dependencies.test = { file = [ " requirements-test.txt " ] }
Hatch使用してパッケージ化された Django アプリケーションがあり、それを実稼働用に固定したい場合。また、開発ツールを別のピン ファイルに固定したいと考えています。 django依存関係として宣言し、 pytestを含むオプションの依存関係devを作成します。
[ build-system ]
requires = [ " hatchling " ]
build-backend = " hatchling.build "
[ project ]
name = " my-cool-django-app "
version = " 42 "
dependencies = [ " django " ]
[ project . optional-dependencies ]
dev = [ " pytest " ]PIN ファイルは次のように簡単に作成できます。
$ pip-compile -o requirements.txt pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile --output-file=requirements.txt pyproject.toml
#
asgiref==3.6.0
# via django
django==4.1.7
# via my-cool-django-app (pyproject.toml)
sqlparse==0.4.3
# via django
$ pip-compile --extra dev -o dev-requirements.txt pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile --extra=dev --output-file=dev-requirements.txt pyproject.toml
#
asgiref==3.6.0
# via django
attrs==22.2.0
# via pytest
django==4.1.7
# via my-cool-django-app (pyproject.toml)
exceptiongroup==1.1.1
# via pytest
iniconfig==2.0.0
# via pytest
packaging==23.0
# via pytest
pluggy==1.0.0
# via pytest
pytest==7.2.2
# via my-cool-django-app (pyproject.toml)
sqlparse==0.4.3
# via django
tomli==2.0.1
# via pytestこれは、アプリケーションを固定するだけでなく、オープンソース Python パッケージの CI を安定に保つのにも最適です。
setup.pyおよびsetup.cfgの要件pip-compile 、 setuptoolsを使用するsetup.pyおよびsetup.cfgベースのプロジェクトも完全にサポートしています。
いつものように依存関係と追加要素を定義し、上記のようにpip-compile実行するだけです。
requirements.in要件に応じてプレーン テキスト ファイルを使用することもできます (たとえば、アプリケーションをパッケージにしたくない場合)。 requirements.inファイルを使用して Django の依存関係を宣言するには:
# requirements.in
django
ここで、 pip-compile requirements.in実行します。
$ pip-compile requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile requirements.in
#
asgiref==3.6.0
# via django
django==4.1.7
# via -r requirements.in
sqlparse==0.4.3
# via djangoそして、すべての Django 依存関係 (およびすべての基礎となる依存関係) が固定された、 requirements.txtを生成します。
(更新要件)=
pip-compileサポートされるファイルで指定された依存関係を満たす最新バージョンを使用して、 requirements.txtファイルを生成します。
pip-compile依存関係を満たす既存のrequirements.txtファイルを見つけた場合、更新が利用可能であっても変更は行われません。
pip-compile既存のrequirements.txt内のすべてのパッケージを強制的に更新するには、 pip-compile --upgradeを実行します。
特定のパッケージを最新または特定のバージョンに更新するには--upgrade-packageまたは-Pフラグを使用します。
# only update the django package
$ pip-compile --upgrade-package django
# update both the django and requests packages
$ pip-compile --upgrade-package django --upgrade-package requests
# update the django package to the latest, and requests to v2.0.0
$ pip-compile --upgrade-package django --upgrade-package requests==2.0.0 --upgradeと--upgrade-package 1 つのコマンドで組み合わせて、許可されるアップグレードに制約を与えることができます。たとえば、リクエストを 3.0 未満の最新バージョンに制限しながらすべてのパッケージをアップグレードするには、次のようにします。
$ pip-compile --upgrade --upgrade-package ' requests<3.0 'バージョン 8.0 以降のpipで利用可能なハッシュ チェック モードを使用したい場合は、 pip-compile --generate-hashesフラグを提供します。
$ pip-compile --generate-hashes requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile --generate-hashes requirements.in
#
asgiref==3.6.0
--hash=sha256:71e68008da809b957b7ee4b43dbccff33d1b23519fb8344e33f049897077afac
--hash=sha256:9567dfe7bd8d3c8c892227827c41cce860b368104c3431da67a0c5a65a949506
# via django
django==4.1.7
--hash=sha256:44f714b81c5f190d9d2ddad01a532fe502fa01c4cb8faf1d081f4264ed15dcd8
--hash=sha256:f2f431e75adc40039ace496ad3b9f17227022e8b11566f4b363da44c7e44761e
# via -r requirements.in
sqlparse==0.4.3
--hash=sha256:0323c0ec29cd52bceabc1b4d9d579e311f3e4961b98d174201d5622a23b85e34
--hash=sha256:69ca804846bb114d2ec380e4360a8a340db83f0ccf3afceeb1404df028f57268
# via django固定された要件をrequirements.txt以外のファイル名で出力するには、 --output-file使用します。これは、複数のファイルをコンパイルする場合に便利です。たとえば、django に異なる制約を付けて、tox を使用して両方のバージョンのライブラリをテストします。
$ pip-compile --upgrade-package ' django<1.0 ' --output-file requirements-django0x.txt
$ pip-compile --upgrade-package ' django<2.0 ' --output-file requirements-django1x.txtまたは、標準出力に出力するには、 --output-file=-を使用します。
$ pip-compile --output-file=- > requirements.txt
$ pip-compile - --output-file=- < requirements.in > requirements.txtpipへの転送オプション有効なpipフラグまたは引数は、 pip-compileの--pip-argsオプションを使用して渡すことができます。
$ pip-compile requirements.in --pip-args " --retries 10 --timeout 30 "pip-compileとpip-syncのプロジェクト レベルのデフォルトを定義するには、要件入力ファイルと同じディレクトリ (標準入力からパイプ入力する場合は現在の作業ディレクトリ) にある構成ファイルにそれらを書き込むことができます。デフォルトでは、 pip-compileとpip-sync両方とも、最初に.pip-tools.tomlファイルを検索し、次にpyproject.tomlを検索します。 --configオプションを使用して代替 TOML 構成ファイルを指定することもできます。
構成値はグローバルに指定することも、コマンド固有に指定することもできます。たとえば、デフォルトで、結果の要件ファイル出力にpipハッシュを生成するには、構成ファイルで次のように指定できます。
[ tool . pip-tools ]
generate-hashes = true複数回使用できるpip-compileおよびpip-syncのオプションは、値が 1 つしかない場合でも、構成ファイル内でリストとして定義する必要があります。
pip-toolsそのサブコマンドのすべての有効なコマンドライン フラグのデフォルト値をサポートします。構成キーにはダッシュの代わりにアンダースコアを含めることができるため、上記を次の形式で指定することもできます。
[ tool . pip-tools ]
generate_hashes = true pip-compileとpip-syncに固有の設定デフォルトは、別のセクションの下に置くことができます。たとえば、デフォルトでpip-compile使用してドライランを実行するには、次のようにします。
[ tool . pip-tools . compile ] # "sync" for pip-sync
dry-run = trueこれは、 --dry-runオプションもあるpip-syncコマンドには影響しません。ローカル設定が同じ名前のグローバル設定よりも優先されることに注意してください。両方が宣言されている場合は常にpip-compileハッシュが生成されますが、グローバルのドライラン設定は破棄されます。
[ tool . pip-tools ]
generate-hashes = true
dry-run = true
[ tool . pip-tools . compile ]
dry-run = false pip-compileコマンドを別のスクリプトでラップしている可能性があります。カスタム スクリプトの利用者の混乱を避けるために、 CUSTOM_COMPILE_COMMAND環境変数を設定することで、要件ファイルの先頭で生成された更新コマンドをオーバーライドできます。
$ CUSTOM_COMPILE_COMMAND= " ./pipcompilewrapper " pip-compile requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# ./pipcompilewrapper
#
asgiref==3.6.0
# via django
django==4.1.7
# via -r requirements.in
sqlparse==0.4.3
# via django互換性のある異なるパッケージをインストールする必要がある異なる環境がある場合は、階層化された要件ファイルを作成し、1 つのレイヤーを使用して他のレイヤーを制限することができます。
たとえば、実稼働環境で最新の2.1リリースが必要な Django プロジェクトがあり、開発中に Django デバッグ ツールバーを使用したい場合は、レイヤーごとに 1 つずつ、2 つの*.inファイルを作成できます。
# requirements.in
django<2.2
開発要件dev-requirements.inの先頭で、 -c requirements.txt使用して、開発要件をrequirements.txtで実稼働用にすでに選択されているパッケージに制限します。
# dev-requirements.in
-c requirements.txt
django-debug-toolbar<2.2
まず、通常どおり、 requirements.txtをコンパイルします。
$ pip-compile
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile
#
django==2.1.15
# via -r requirements.in
pytz==2023.3
# via django
ここで開発要件をコンパイルすると、 requirements.txtファイルが制約として使用されます。
$ pip-compile dev-requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile dev-requirements.in
#
django==2.1.15
# via
# -c requirements.txt
# django-debug-toolbar
django-debug-toolbar==2.1
# via -r dev-requirements.in
pytz==2023.3
# via
# -c requirements.txt
# django
sqlparse==0.4.3
# via django-debug-toolbar上でわかるように、Django の2.2リリースが利用可能であっても、開発要件には制約があったため、Django の2.1バージョンのみが含まれています。これで、コンパイルされた両方の要件ファイルを開発環境に安全にインストールできるようになりました。
実稼働段階で要件をインストールするには、次を使用します。
$ pip-sync次の方法で開発段階で要件をインストールできます。
$ pip-sync requirements.txt dev-requirements.txtpip-compileプリコミットのフックとして使用することもできます。手順については、コミット前のドキュメントを参照してください。サンプル.pre-commit-config.yaml :
repos :
- repo : https://github.com/jazzband/pip-tools
rev : 7.4.1
hooks :
- id : pip-compile argsやfilesを設定してpip-compile args をカスタマイズすることもできます。次に例を示します。
repos :
- repo : https://github.com/jazzband/pip-tools
rev : 7.4.1
hooks :
- id : pip-compile
files : ^requirements/production.(in|txt)$
args : [--index-url=https://example.com, requirements/production.in]複数の要件ファイルがある場合は、ファイルごとにフックを作成してください。
repos :
- repo : https://github.com/jazzband/pip-tools
rev : 7.4.1
hooks :
- id : pip-compile
name : pip-compile setup.py
files : ^(setup.py|requirements.txt)$
- id : pip-compile
name : pip-compile requirements-dev.in
args : [requirements-dev.in]
files : ^requirements-dev.(in|txt)$
- id : pip-compile
name : pip-compile requirements-lint.in
args : [requirements-lint.in]
files : ^requirements-lint.(in|txt)$
- id : pip-compile
name : pip-compile requirements.in
args : [requirements.in]
files : ^requirements.(in|txt)$pip-syncの使用例これで、 requirements.txtが完成したので、 pip-sync使用して仮想環境を更新し、その内容を正確に反映することができます。これにより、 requirements.txt内容と一致するために必要なものがすべてインストール/アップグレード/アンインストールされます。
pip-syncまたはpython -m piptools syncを使用して実行します。複数の Python バージョンを使用する場合は、Windows ではpy -XY -m piptools sync実行し、他のシステムではpythonX.Y -m piptools syncを実行することもできます。
どのパッケージをインストールまたはアップグレードするかを特定するには、 pip-syncプロジェクトと同じ仮想環境にインストールして実行する必要があります。
注意: pip-sync 、 pip-compileによって生成されたrequirements.txtでのみ使用することを目的としています。
$ pip-sync
Uninstalling flake8-2.4.1:
Successfully uninstalled flake8-2.4.1
Collecting click==4.1
Downloading click-4.1-py2.py3-none-any.whl (62kB)
100% |................................| 65kB 1.8MB/s
Found existing installation: click 4.0
Uninstalling click-4.0:
Successfully uninstalled click-4.0
Successfully installed click-4.1複数の*.txt依存関係リストを同期するには、コマンド ライン引数を介してそれらを渡すだけです。
$ pip-sync dev-requirements.txt requirements.txt空の引数を渡すと、デフォルトでrequirements.txtになります。
有効なpip installフラグまたは引数は、 pip-syncの--pip-argsオプションで渡すことができます。
$ pip-sync requirements.txt --pip-args " --no-cache-dir --no-deps "注: pip-sync setuptools 、 pip 、またはpip-tools自体のようなパッケージ化ツールをアップグレードまたはアンインストールしません。これらのパッケージをアップグレードするには、 python -m pip install --upgradeを使用します。
requirements.inとrequirements.txtソース管理にコミットする必要がありますか?一般的にはそうです。ソース管理から利用可能な再現可能な環境インストールが必要な場合は、はい、 requirements.inとrequirements.txtの両方をソース管理にコミットする必要があります。
複数の Python 環境にデプロイする場合 (以下のセクションを参照)、Python 環境ごとに個別の出力ファイルをコミットする必要があることに注意してください。 {env}-requirements.txt形式 (例: win32-py3.7-requirements.txt 、 macos-py3.10-requirements.txtなど) を使用することをお勧めします。
requirements.inおよびpip-compileのrequirements.txt間での使用パッケージの依存関係は、パッケージがインストールされている Python 環境に応じて変化する可能性があります。ここでは、Python 環境をオペレーティング システム、Python バージョン (3.7、3.8 など)、Python 実装 (CPython、PyPy など) の組み合わせとして定義します。正確な定義については、PEP 508 環境マーカーの可能な組み合わせを参照してください。
結果として得られるrequirements.txt環境ごとに異なる可能性があるため、ユーザーは各Python環境で個別にpip-compile実行して、各環境に有効なrequirements.txtを生成する必要があります。通常のpip環境間使用の場合と同じように、必要に応じて PEP 508 環境マーカーを使用して、同じrequirements.inすべての環境のソース ファイルとして使用できます。
生成されたrequirements.txtがすべてのPython環境でまったく同じであれば、Python環境間で安全に使用できます。ただし、パッケージの更新により環境依存の依存関係が導入される可能性があり、新しく生成されたrequirements.txtも環境依存になる可能性があるため、ユーザーは注意する必要があります。一般的なルールとして、問題を回避するために、対象となる各 Python 環境で常にpip-compile実行することをお勧めします。
pip-toolsビルドの再現性を向上させる優れたツールです。ただし、留意すべき点がいくつかあります。
pip-compile環境ごとに異なる結果を生成します。pip PIP_CONSTRAINT環境変数とともに使用する必要があります。先ほどのpyproject.toml例を続けると、次のように単一のロック ファイルを作成できます。
$ pip-compile --all-build-deps --all-extras --output-file=constraints.txt --strip-extras pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.9
# by the following command:
#
# pip-compile --all-build-deps --all-extras --output-file=constraints.txt --strip-extras pyproject.toml
#
asgiref==3.5.2
# via django
attrs==22.1.0
# via pytest
backports-zoneinfo==0.2.1
# via django
django==4.1
# via my-cool-django-app (pyproject.toml)
editables==0.3
# via hatchling
hatchling==1.11.1
# via my-cool-django-app (pyproject.toml::build-system.requires)
iniconfig==1.1.1
# via pytest
packaging==21.3
# via
# hatchling
# pytest
pathspec==0.10.2
# via hatchling
pluggy==1.0.0
# via
# hatchling
# pytest
py==1.11.0
# via pytest
pyparsing==3.0.9
# via packaging
pytest==7.1.2
# via my-cool-django-app (pyproject.toml)
sqlparse==0.4.2
# via django
tomli==2.0.1
# via
# hatchling
# pytest一部のビルド バックエンドは、PEP 517 および PEP 660 で説明されているget_requires_for_build_フックを使用して、ビルドの依存関係を動的に要求する場合もあります。これは、次のいずれかのサフィックスが付いて出力に示されます。
(pyproject.toml::build-system.backend::editable)(pyproject.toml::build-system.backend::sdist)(pyproject.toml::build-system.backend::wheel)pip-compile-multi - 複数の相互参照要件ファイル用の pip-compile コマンド ラッパー。
pipdeptree は、インストールされているパッケージの依存関係ツリーを出力します。
requirements.in requirements.txt構文の強調表示:
このセクションでは、現在非推奨になっているpip-tools機能をリストします。
--allow-unsafe動作がデフォルトで有効になります (#989)。古い動作を維持するには、 --no-allow-unsafeを使用します。今後の変更に適応するために、今すぐ--allow-unsafeを渡すことをお勧めします。--resolver=backtrackingです。--strip-extras動作がデフォルトで有効になります (#1613)。古い動作を維持するには、 --no-strip-extrasを使用します。デフォルトのバックトラッキング リゾルバーまたは非推奨のレガシー リゾルバーから選択できます。
従来のリゾルバーは依存関係の解決に失敗することがあります。バックトラッキング リゾルバーはより堅牢ですが、一般に実行に時間がかかることがあります。
--resolver=legacyするとレガシー リゾルバーを引き続き使用できますが、これは非推奨であり、将来のリリースでは削除される予定であることに注意してください。
