Locking environments環境のロック
Locking is to take a dependency, e.g., ruff, and write an exact version to use to a file. When
working with many dependencies, it is useful to lock the exact versions so the environment can be
reproduced. Without locking, the versions of dependencies could change over time, when using a
different tool, or across platforms.ロックとは、依存関係（例：ruff）を取り、使用する正確なバージョンをファイルに書き込むことです。多くの依存関係を扱う際には、環境を再現できるように正確なバージョンをロックすることが有用です。ロックを行わないと、依存関係のバージョンは時間とともに変わる可能性があり、異なるツールを使用したり、プラットフォーム間で異なる場合があります。
Locking requirements要件のロック
uv allows dependencies to be locked in the requirements.txt format. It is recommended to use the
standard pyproject.toml to define dependencies, but other dependency formats are supported as
well. See the documentation on declaring dependencies for more details on how to
define dependencies.uvは、requirements.txt形式で依存関係をロックすることを可能にします。依存関係を定義するために標準のpyproject.tomlを使用することが推奨されますが、他の依存関係形式もサポートされています。依存関係を定義する方法の詳細については、依存関係の宣言に関するドキュメントを参照してください。
To lock dependencies declared in a pyproject.toml:pyproject.tomlで宣言された依存関係をロックするには：
Note by default the uv pip compile output is just displayed and --output-file / -o argument is
needed to write to a file.デフォルトでは、uv pip compileの出力は表示されるだけで、ファイルに書き込むには--output-file / -o引数が必要です。
To lock dependencies declared in a requirements.in:requirements.inで宣言された依存関係をロックするには：
To lock dependencies declared in multiple files:複数のファイルに宣言された依存関係をロックするには:
uv also supports legacy setup.py and setup.cfg formats. To lock dependencies declared in a
setup.py:uvはレガシーのsetup.pyおよびsetup.cfgフォーマットもサポートしています。setup.pyに宣言された依存関係をロックするには:
To lock dependencies from stdin, use -:標準入力から依存関係をロックするには、-を使用します:
To lock with optional dependencies enabled, e.g., the "foo" extra:オプションの依存関係を有効にしてロックするには、例えば「foo」エクストラの場合:
To lock with all optional dependencies enabled:すべてのオプションの依存関係を有効にしてロックするには:
Note extras are not supported with the requirements.in format.エクストラはrequirements.inフォーマットではサポートされていないことに注意してください。
To lock a dependency group in the current project directory's pyproject.toml, for example the
group foo:現在のプロジェクトディレクトリのpyproject.tomlで依存関係グループをロックするには、例えばグループfooの場合:
Important重要
A --group flag has to be added to pip-tools' pip compile, although they're considering it. We expect to support whatever syntax and semantics they adopt.--groupフラグをpip-toolsのpip compileに追加する必要があります。ただし、彼らはそれを検討しています。私たちは、彼らが採用する構文と意味論をサポートすることを期待しています。
To specify the project directory where groups should be sourced from:グループがソースされるプロジェクトディレクトリを指定するには:
Alternatively, you can specify a path to a pyproject.toml for each group:また、各グループのためにpyproject.tomlへのパスを指定することもできます:
Note注意
--group flags do not apply to other specified sources. For instance,
uv pip compile some/path/pyproject.toml --group foo sources foo
from ./pyproject.toml and not some/path/pyproject.toml.--group フラグは他の指定されたソースには適用されません。例えば、
uv pip compile some/path/pyproject.toml --group foo は ./pyproject.toml から foo ソースを取得し、some/path/pyproject.toml からは取得しません。
Upgrading requirements依存関係のアップグレード
When using an output file, uv will consider the versions pinned in an existing output file. If a dependency is pinned it will not be upgraded on a subsequent compile run. For example:出力ファイルを使用する場合、uv は既存の出力ファイルに固定されたバージョンを考慮します。もし依存関係が固定されている場合、次回のコンパイル実行ではアップグレードされません。例えば：
$ echo "ruff==0.3.0" > requirements.txt
$ echo "ruff" | uv pip compile - -o requirements.txt
# This file was autogenerated by uv via the following command:
# uv pip compile - -o requirements.txt
ruff==0.3.0
To upgrade a dependency, use the --upgrade-package flag:依存関係をアップグレードするには、--upgrade-package フラグを使用します：
To upgrade all dependencies, there is an --upgrade flag.すべての依存関係をアップグレードするには、--upgrade フラグがあります。
Syncing an environment環境の同期
Dependencies can be installed directly from their definition files or from compiled
requirements.txt files with uv pip install. See the documentation on
installing packages from files for more details.依存関係は、その定義ファイルまたはコンパイルされた requirements.txt ファイルから直接インストールできます。詳細については、ファイルからパッケージをインストールする のドキュメントを参照してください。
When installing with uv pip install, packages that are already installed will not be removed
unless they conflict with the lockfile. This means that the environment can have dependencies that
aren't declared in the lockfile, which isn't great for reproducibility. To ensure the environment
exactly matches the lockfile, use uv pip sync instead.uv pip install でインストールする際、すでにインストールされているパッケージはロックファイルと競合しない限り削除されません。これは、環境にロックファイルに宣言されていない依存関係が存在する可能性があることを意味し、再現性には良くありません。環境がロックファイルと正確に一致することを保証するには、代わりに uv pip sync を使用してください。
To sync an environment with a requirements.txt file:requirements.txt ファイルで環境を同期するには：
To sync an environment with a PEP 751 pylock.toml file:PEP 751 pylock.toml ファイルで環境を同期するには：
Adding constraints制約の追加
Constraints files are requirements.txt-like files that only control the version of a requirement
that's installed. However, including a package in a constraints file will not trigger the
installation of that package. Constraints can be used to add bounds to dependencies that are not
dependencies of the current project.制約ファイルは、インストールされる要件のバージョンのみを制御するrequirements.txtのようなファイルです。しかし、制約ファイルにパッケージを含めても、そのパッケージのインストールはトリガーされません。制約は、現在のプロジェクトの依存関係ではない依存関係に境界を追加するために使用できます。
To define a constraint, define a bound for a package:制約を定義するには、パッケージの境界を定義します：
To use a constraints file:制約ファイルを使用するには：
Note that multiple constraints can be defined in each file and multiple files can be used.各ファイルに複数の制約を定義でき、複数のファイルを使用することもできることに注意してください。
uv will also read constraint-dependencies from the pyproject.toml at the workspace root, and
append them to those specified in the constraints file.uvは、ワークスペースのルートにあるpyproject.tomlからconstraint-dependenciesも読み取り、それを制約ファイルに指定されたものに追加します。
Adding build constraintsビルド制約の追加
Similar to constraints, but specifically for build-time dependencies, including those required
when building runtime dependencies.constraintsに似ていますが、特にビルド時の依存関係、つまりランタイム依存関係を構築する際に必要なものを含みます。
Build constraint files are requirements.txt-like files that only control the version of a
build-time requirement. However, including a package in a build constraints file will not trigger
its installation at build time; instead, constraints apply only when the package is required as a
direct or transitive build-time dependency. Build constraints can be used to add bounds to
dependencies that are not explicitly declared as build-time dependencies of the current project.ビルド制約ファイルは、ビルド時の要件のバージョンのみを制御するrequirements.txtのようなファイルです。しかし、ビルド制約ファイルにパッケージを含めても、ビルド時にそのインストールはトリガーされません。代わりに、制約はパッケージが直接または間接的なビルド時の依存関係として必要な場合にのみ適用されます。ビルド制約は、現在のプロジェクトのビルド時の依存関係として明示的に宣言されていない依存関係に境界を追加するために使用できます。
For example, if a package defines its build dependencies as follows:例えば、パッケージがそのビルド依存関係を次のように定義している場合：
Build constraints could be used to ensure that a specific version of setuptools is used for every
package in the workspace:ビルド制約は、ワークスペース内のすべてのパッケージに対して特定のバージョンの setuptools が使用されることを保証するために使用できます：
uv will also read build-constraint-dependencies from the pyproject.toml at the workspace root,
and append them to those specified in the build constraints file.uvはまた、ワークスペースのルートにある pyproject.toml から build-constraint-dependencies を読み取り、ビルド制約ファイルに指定されたものに追加します。
Overriding dependency versions依存関係のバージョンの上書き
Overrides files are requirements.txt-like files that force a specific version of a requirement to
be installed, regardless of the requirements declared by any constituent package, and regardless of
whether this would be considered an invalid resolution.オーバーライドファイルは、requirements.txt に似たファイルで、構成パッケージによって宣言された要件に関係なく、特定のバージョンの要件を強制的にインストールさせます。また、これが無効な解決と見なされるかどうかにも関係ありません。
While constraints are additive, in that they're combined with the requirements of the constituent packages, overrides are absolute, in that they completely replace the requirements of the constituent packages.制約は構成パッケージの要件と組み合わされるため 加算的 ですが、オーバーライドは構成パッケージの要件を完全に置き換えるため 絶対的 です。
Overrides are most often used to remove upper bounds from a transitive dependency. For example, if
a requires c>=1.0,<2.0 and b requires c>=2.0 and the current project requires a and b
then the dependencies cannot be resolved.オーバーライドは、遷移依存関係から上限を削除するために最もよく使用されます。たとえば、a が c>=1.0,<2.0 を必要とし、b が c>=2.0 を必要とし、現在のプロジェクトが a と b を必要とする場合、依存関係は解決できません。
To define an override, define the new requirement for the problematic package:オーバーライドを定義するには、問題のあるパッケージの新しい要件を定義します：
To use an overrides file:オーバーライドファイルを使用するには：
Now, resolution can succeed. However, note that if a is correct that it does not support
c>=2.0 then a runtime error will likely be encountered when using the packages.これで、解決が成功する可能性があります。ただし、a が 正しい ものであり、c>=2.0 をサポートしていない場合、パッケージを使用する際にランタイムエラーが発生する可能性が高いことに注意してください。
Note that multiple overrides can be defined in each file and multiple files can be used.各ファイルに複数のオーバーライドを定義でき、複数のファイルを使用することもできることに注意してください。