Skip to content

Resolution解決

Resolution is the process of taking a list of requirements and converting them to a list of package versions that fulfill the requirements. Resolution requires recursively searching for compatible versions of packages, ensuring that the requested requirements are fulfilled and that the requirements of the requested packages are compatible.解決は、要件のリストを取得し、それを要件を満たすパッケージのバージョンのリストに変換するプロセスです。解決には、互換性のあるパッケージのバージョンを再帰的に検索し、要求された要件が満たされていること、及び要求されたパッケージの要件が互換性があることを確認する必要があります。

Dependencies依存関係

Most projects and packages have dependencies. Dependencies are other packages that are necessary in order for the current package to work. A package defines its dependencies as requirements, roughly a combination of a package name and acceptable versions. The dependencies defined by the current project are called direct dependencies. The dependencies added by each dependency of the current project are called indirect or transitive dependencies.ほとんどのプロジェクトやパッケージには依存関係があります。依存関係とは、現在のパッケージが動作するために必要な他のパッケージです。パッケージは、その依存関係を要件として定義し、概ねパッケージ名と許容されるバージョンの組み合わせです。現在のプロジェクトによって定義された依存関係は直接依存関係と呼ばれます。現在のプロジェクトの各依存関係によって追加された依存関係は間接または推移的依存関係と呼ばれます。

Note注意

See the dependency specifiers page in the Python Packaging documentation for details about dependencies.依存関係の詳細については、Python Packaging ドキュメントの依存関係指定子ページを参照してください。

Basic examples基本的な例

To help demonstrate the resolution process, consider the following dependencies:解決プロセスを示すために、次の依存関係を考慮してください：

  • The project depends on foo and bar.プロジェクトはfooとbarに依存しています。
  • foo has one version, 1.0.0:
    • foo 1.0.0 depends on lib>=1.0.0.foo 1.0.0 は lib>=1.0.0 に依存しています。
  • bar has one version, 1.0.0:
    • bar 1.0.0 depends on lib>=2.0.0.bar 1.0.0 は lib>=2.0.0 に依存しています。
  • lib has two versions, 1.0.0 and 2.0.0. Both versions have no dependencies.lib には2つのバージョン、1.0.0と2.0.0があります。どちらのバージョンも依存関係はありません。

In this example, the resolver must find a set of package versions which satisfies the project requirements. Since there is only one version of both foo and bar, those will be used. The resolution must also include the transitive dependencies, so a version of lib must be chosen. foo 1.0.0 allows all available versions of lib, but bar 1.0.0 requires lib>=2.0.0 so lib 2.0.0 must be used.この例では、リゾルバはプロジェクトの要件を満たすパッケージバージョンのセットを見つける必要があります。foo と bar の両方にバージョンは1つしかないため、それらが使用されます。解決には推移的依存関係も含める必要があるため、lib のバージョンを選択する必要があります。foo 1.0.0 は利用可能なすべてのバージョンの lib を許可しますが、bar 1.0.0 は lib>=2.0.0 を要求するため、lib 2.0.0 を使用する必要があります。

In some resolutions, there may be more than one valid solution. Consider the following dependencies:いくつかの解決では、複数の有効な解決策が存在する場合があります。次の依存関係を考えてみてください：

  • The project depends on foo and bar.プロジェクトは foo と bar に依存しています。
  • foo has two versions, 1.0.0 and 2.0.0:
    • foo 1.0.0 has no dependencies.foo 1.0.0 には依存関係がありません。
    • foo 2.0.0 depends on lib==2.0.0.foo 2.0.0 は lib==2.0.0 に依存しています。
  • bar has two versions, 1.0.0 and 2.0.0:
    • bar 1.0.0 has no dependencies.bar 1.0.0 には依存関係がありません。
    • bar 2.0.0 depends on lib==1.0.0bar 2.0.0 は lib==1.0.0 に依存しています。
  • lib has two versions, 1.0.0 and 2.0.0. Both versions have no dependencies.lib には 1.0.0 と 2.0.0 の2つのバージョンがあります。どちらのバージョンにも依存関係はありません。

In this example, some version of both foo and bar must be selected; however, determining which version requires considering the dependencies of each version of foo and bar. foo 2.0.0 and bar 2.0.0 cannot be installed together as they conflict on their required version of lib, so the resolver must select either foo 1.0.0 (along with bar 2.0.0) or bar 1.0.0 (along with foo 1.0.0). Both are valid solutions, and different resolution algorithms may yield either result.この例では、foo と bar の両方のバージョンのいずれかを選択する必要があります。ただし、どのバージョンを選ぶかは、各バージョンの foo と bar の依存関係を考慮する必要があります。foo 2.0.0 と bar 2.0.0 は、lib の必要なバージョンが競合するため、一緒にインストールすることはできません。したがって、リゾルバは foo 1.0.0（bar 2.0.0 と共に）または bar 1.0.0（foo 1.0.0 と共に）のいずれかを選択する必要があります。どちらも有効な解決策であり、異なる解決アルゴリズムがどちらの結果をもたらす可能性があります。

Platform markersプラットフォームマーカー

Markers allow attaching an expression to requirements that indicate when the dependency should be used. For example bar ; python_version < "3.9" indicates that bar should only be installed on Python 3.8 and earlier.マーカーは、依存関係を使用すべき時期を示す要件に式を付けることを可能にします。例えば、bar ; python_version < "3.9" は、bar が Python 3.8 およびそれ以前のバージョンでのみインストールされるべきことを示します。

Markers are used to adjust a package's dependencies based on the current environment or platform. For example, markers can be used to modify dependencies by operating system, CPU architecture, Python version, Python implementation, and more.マーカーは、現在の環境やプラットフォームに基づいてパッケージの依存関係を調整するために使用されます。例えば、マーカーはオペレーティングシステム、CPU アーキテクチャ、Python バージョン、Python 実装などによって依存関係を変更するために使用できます。

Note注意

See the environment markers section in the Python Packaging documentation for more details about markers.マーカーに関する詳細は、Python Packaging ドキュメントの 環境マーカー セクションを参照してください。

Markers are important for resolution because their values change the required dependencies. Typically, Python package resolvers use the markers of the current platform to determine which dependencies to use since the package is often being installed on the current platform. However, for locking dependencies this is problematic — the lockfile would only work for developers using the same platform the lockfile was created on. To solve this problem, platform-independent, or "universal" resolvers exist.マーカーは解決において重要です。なぜなら、その値が必要な依存関係を変更するからです。通常、Python パッケージリゾルバは、現在の プラットフォームのマーカーを使用して、どの依存関係を使用するかを決定します。なぜなら、パッケージはしばしば 現在の プラットフォームに インストール されるからです。しかし、ロック された依存関係にとってはこれは問題です — ロックファイルは、ロックファイルが作成されたのと同じプラットフォームを使用している開発者にしか機能しません。この問題を解決するために、プラットフォームに依存しない、または「ユニバーサル」リゾルバが存在します。

uv supports both platform-specific and universal resolution.uv は、プラットフォーム固有の 解決と ユニバーサル 解決の両方をサポートしています。

Platform-specific resolutionプラットフォーム固有の解決

By default, uv's pip interface, i.e., uv pip compile, produces a resolution that is platform-specific, like pip-tools. There is no way to use platform-specific resolution in the uv's project interface.デフォルトでは、uv の pip インターフェース、すなわち uv pip compile は、pip-tools のようにプラットフォーム固有の解決を生成します。uv のプロジェクトインターフェースでは、プラットフォーム固有の解決を使用する方法はありません。

uv also supports resolving for specific, alternate platforms and Python versions with the --python-platform and --python-version options. For example, if using Python 3.12 on macOS, uv pip compile --python-platform linux --python-version 3.10 requirements.in can be used to produce a resolution for Python 3.10 on Linux instead. Unlike universal resolution, during platform-specific resolution, the provided --python-version is the exact python version to use, not a lower bound.uvは、特定の代替プラットフォームおよびPythonバージョンの解決をサポートしています。 --python-platformおよび--python-versionオプションを使用します。たとえば、macOSでPython 3.12を使用している場合、 uv pip compile --python-platform linux --python-version 3.10 requirements.inを使用して、代わりにLinux上のPython 3.10の解決を生成できます。 ユニバーサル解決とは異なり、プラットフォーム固有の解決中は、提供された--python-versionが使用する正確なPythonバージョンであり、 下限ではありません。

Note注意

Python's environment markers expose far more information about the current machine than can be expressed by a simple --python-platform argument. For example, the platform_version marker on macOS includes the time at which the kernel was built, which can (in theory) be encoded in package requirements. uv's resolver makes a best-effort attempt to generate a resolution that is compatible with any machine running on the target --python-platform, which should be sufficient for most use cases, but may lose fidelity for complex package and platform combinations.Pythonの環境マーカーは、単純な--python-platform引数では表現できない、現在のマシンに関するはるかに多くの情報を公開します。 たとえば、macOSのplatform_versionマーカーには、カーネルがビルドされた時刻が含まれており、これは（理論的には）パッケージ要件にエンコードできます。 uvのリゾルバーは、ターゲット--python-platform上で動作する任意のマシンと互換性のある解決を生成するために最善を尽くします。 これはほとんどのユースケースには十分ですが、複雑なパッケージとプラットフォームの組み合わせでは忠実度を失う可能性があります。

Universal resolutionユニバーサル解決

uv's lockfile (uv.lock) is created with a universal resolution and is portable across platforms. This ensures that dependencies are locked for everyone working on the project, regardless of operating system, architecture, and Python version. The uv lockfile is created and modified by project commands such as uv lock, uv sync, and uv add.uvのロックファイル（uv.lock）はユニバーサル解決で作成され、プラットフォーム間でポータブルです。 これにより、オペレーティングシステム、アーキテクチャ、およびPythonバージョンに関係なく、プロジェクトに取り組むすべての人の依存関係がロックされます。 uvのロックファイルは、プロジェクトコマンド（uv lock、uv sync、uv addなど）によって作成および変更されます。

Universal resolution is also available in uv's pip interface, i.e., uv pip compile, with the --universal flag. The resulting requirements file will contain markers to indicate which platform each dependency is relevant for.ユニバーサル解決は、uvのpipインターフェースでも利用可能で、すなわち、 uv pip compileで--universalフラグを使用します。結果として得られる要件ファイルには、各依存関係が関連するプラットフォームを示すマーカーが含まれます。

During universal resolution, a package may be listed multiple times with different versions or URLs if different versions are needed for different platforms — the markers determine which version will be used. A universal resolution is often more constrained than a platform-specific resolution, since we need to take the requirements for all markers into account.ユニバーサル解決中、異なるプラットフォームに必要な異なるバージョンがある場合、パッケージは異なるバージョンまたはURLで複数回リストされることがあります。 マーカーはどのバージョンが使用されるかを決定します。ユニバーサル解決は、すべてのマーカーの要件を考慮する必要があるため、 プラットフォーム固有の解決よりも制約が多いことがよくあります。

During universal resolution, all required packages must be compatible with the entire range of requires-python declared in the pyproject.toml. For example, if a project's requires-python is >=3.8, resolution will fail if all versions of given dependency require Python 3.9 or later, since the dependency lacks a usable version for (e.g.) Python 3.8, the lower bound of the project's supported range. In other words, the project's requires-python must be a subset of the requires-python of all its dependencies.ユニバーサル解決中、すべての必要なパッケージは、全体の範囲のrequires-pythonと互換性がある必要があります。 たとえば、プロジェクトのrequires-pythonが>=3.8の場合、指定された依存関係のすべてのバージョンがPython 3.9以降を必要とする場合、解決は失敗します。 これは、依存関係が（例：）Python 3.8の使用可能なバージョンを欠いているためであり、プロジェクトのサポートされる範囲の下限です。 言い換えれば、プロジェクトのrequires-pythonは、すべての依存関係のrequires-pythonのサブセットでなければなりません。

When selecting the compatible version for a given dependency, uv will (by default) attempt to choose the latest compatible version for each supported Python version. For example, if a project's requires-python is >=3.8, and the latest version of a dependency requires Python 3.9 or later, while all prior versions supporting Python 3.8, the resolver will select the latest version for users running Python 3.9 or later, and previous versions for users running Python 3.8.特定の依存関係の互換性のあるバージョンを選択する際、uvは (デフォルトで) 各サポートされているPythonバージョンに対して最新の互換性のあるバージョンを選択しようとします。 たとえば、プロジェクトのrequires-pythonが>=3.8であり、依存関係の最新バージョンがPython 3.9以降を必要とし、 すべての以前のバージョンがPython 3.8をサポートしている場合、リゾルバーはPython 3.9以降を実行しているユーザーには最新バージョンを選択し、 Python 3.8を実行しているユーザーには以前のバージョンを選択します。

When evaluating requires-python ranges for dependencies, uv only considers lower bounds and ignores upper bounds entirely. For example, >=3.8, <4 is treated as >=3.8. Respecting upper bounds on requires-python often leads to formally correct but practically incorrect resolutions, as, e.g., resolvers will backtrack to the first published version that omits the upper bound (see: Requires-Python upper limits).依存関係のrequires-python範囲を評価する際、uvは下限のみを考慮し、上限は完全に無視します。 たとえば、>=3.8, <4は>=3.8として扱われます。requires-pythonの上限を尊重すると、形式的には正しいが実際には不正確な解決につながることがよくあります。 たとえば、リゾルバーは上限を省略した最初に公開されたバージョンにバックトラックします（参照： Requires-Pythonの上限）。

Limited resolution environments制限された解決環境

By default, the universal resolver attempts to solve for all platforms and Python versions.デフォルトでは、ユニバーサルリゾルバーはすべてのプラットフォームとPythonバージョンの解決を試みます。

If your project supports only a limited set of platforms or Python versions, you can constrain the set of solved platforms via the environments setting, which accepts a list of PEP 508 environment markers. In other words, you can use the environments setting to reduce the set of supported platforms.プロジェクトが限られたプラットフォームまたはPythonバージョンのみをサポートしている場合、environments設定を使用して解決されたプラットフォームのセットを制約できます。この設定は、PEP 508環境マーカーのリストを受け入れます。言い換えれば、environments設定を使用してサポートされるプラットフォームのセットを減少させることができます。

For example, to constrain the lockfile to macOS and Linux, and avoid solving for Windows:例えば、ロックファイルをmacOSとLinuxに制約し、Windowsの解決を避けるには:

pyproject.toml
[tool.uv]
environments = [
    "sys_platform == 'darwin'",
    "sys_platform == 'linux'",
]

Or, to avoid solving for alternative Python implementations:または、代替のPython実装の解決を避けるには:

pyproject.toml
[tool.uv]
environments = [
    "implementation_name == 'cpython'"
]

Entries in the environments setting must be disjoint (i.e., they must not overlap). For example, sys_platform == 'darwin' and sys_platform == 'linux' are disjoint, but sys_platform == 'darwin' and python_version >= '3.9' are not, since both could be true at the same time.environments設定のエントリは互いに排他的でなければなりません（つまり、重複してはいけません）。例えば、sys_platform == 'darwin'とsys_platform == 'linux'は排他的ですが、sys_platform == 'darwin'とpython_version >= '3.9'は重複しているため、同時に真である可能性があります。

Required environments必要な環境

In the Python ecosystem, packages can be published as source distributions, built distributions (wheels), or both; but to install a package, a built distribution is required. If a package lacks a built distribution, or lacks a distribution for the current platform or Python version (built distributions are often platform-specific), uv will attempt to build the package from source, then install the resulting built distribution.Pythonエコシステムでは、パッケージはソース配布、ビルド配布（ホイール）、またはその両方として公開できますが、パッケージをインストールするにはビルド配布が必要です。パッケージにビルド配布が欠けている場合、または現在のプラットフォームまたはPythonバージョンの配布が欠けている場合（ビルド配布はプラットフォーム固有であることが多い）、uvはソースからパッケージをビルドし、その結果得られたビルド配布をインストールしようとします。

Some packages (like PyTorch) publish built distributions, but omit a source distribution. Such packages are only installable on platforms for which a built distribution is available. For example, if a package publishes built distributions for Linux, but not macOS or Windows, then that package will only be installable on Linux.一部のパッケージ（PyTorchなど）はビルド配布を公開しますが、ソース配布を省略します。そのようなパッケージはのみビルド配布が利用可能なプラットフォームでインストール可能です。例えば、あるパッケージがLinux用のビルド配布を公開しているが、macOSやWindows用は公開していない場合、そのパッケージはのみLinuxにインストール可能です。

Packages that lack source distributions cause problems for universal resolution, since there will typically be at least one platform or Python version for which the package is not installable.ソース配布が欠けているパッケージは、通常、インストールできないプラットフォームまたはPythonバージョンが少なくとも1つ存在するため、ユニバーサル解決に問題を引き起こします。

By default, uv requires each such package to include at least one wheel that is compatible with the target Python version. The required-environments setting can be used to ensure that the resulting resolution contains wheels for specific platforms, or fails if no such wheels are available. The setting accepts a list of PEP 508 environment markers.デフォルトでは、uvはそのような各パッケージがターゲットPythonバージョンと互換性のあるホイールを少なくとも1つ含むことを要求します。required-environments設定を使用すると、結果の解決に特定のプラットフォーム用のホイールが含まれることを保証するか、そのようなホイールが利用できない場合は失敗します。この設定は、PEP 508環境マーカーのリストを受け入れます。

While the environments setting limits the set of environments that uv will consider when resolving dependencies, required-environments expands the set of platforms that uv must support when resolving dependencies.environments設定は、uvが依存関係を解決する際に考慮する環境のセットを制限しますが、required-environmentsは、uvが依存関係を解決する際に必ずサポートしなければならないプラットフォームのセットを拡張します。

For example, environments = ["sys_platform == 'darwin'"] would limit uv to solving for macOS (and ignoring Linux and Windows). On the other hand, required-environments = ["sys_platform == 'darwin'"] would require that any package without a source distribution include a wheel for macOS in order to be installable (and would fail if no such wheel is available).例えば、environments = ["sys_platform == 'darwin'"]は、uvをmacOSの解決に制限し（LinuxとWindowsを無視します）。一方、required-environments = ["sys_platform == 'darwin'"]は、ソース配布がないパッケージがインストール可能であるためには、macOS用のホイールを含むことを要求します（そのようなホイールが利用できない場合は失敗します）。

In practice, required-environments can be useful for declaring explicit support for non-latest platforms, since this often requires backtracking past the latest published versions of those packages. For example, to guarantee that any built distribution-only packages includes support for Intel macOS:実際には、required-environmentsは最新ではないプラットフォームに対する明示的なサポートを宣言するのに役立ちます。これは、しばしばそれらのパッケージの最新の公開バージョンを超えて遡る必要があるためです。たとえば、ビルドされた配布専用パッケージがIntel macOSのサポートを含むことを保証するためには：

pyproject.toml
[tool.uv]
required-environments = [
    "sys_platform == 'darwin' and platform_machine == 'x86_64'"
]

Dependency preferences依存関係の優先順位

If resolution output file exists, i.e., a uv lockfile (uv.lock) or a requirements output file (requirements.txt), uv will prefer the dependency versions listed there. Similarly, if installing a package into a virtual environment, uv will prefer the already installed version if present. This means that locked or installed versions will not change unless an incompatible version is requested or an upgrade is explicitly requested with --upgrade.解決出力ファイルが存在する場合、すなわち、uvロックファイル（uv.lock）または要件出力ファイル（requirements.txt）がある場合、uvはそこにリストされた依存関係のバージョンを優先します。同様に、仮想環境にパッケージをインストールする場合、uvは既にインストールされているバージョンが存在する場合はそれを優先します。これは、ロックされたバージョンやインストールされたバージョンは、互換性のないバージョンが要求されるか、--upgradeで明示的にアップグレードが要求されない限り、変更されないことを意味します。

Resolution strategy解決戦略

By default, uv tries to use the latest version of each package. For example, uv pip install flask>=2.0.0 will install the latest version of Flask, e.g., 3.0.0. If flask>=2.0.0 is a dependency of the project, only flask 3.0.0 will be used. This is important, for example, because running tests will not check that the project is actually compatible with its stated lower bound of flask 2.0.0.デフォルトでは、uvは各パッケージの最新バージョンを使用しようとします。たとえば、uv pip install flask>=2.0.0はFlaskの最新バージョン、例えば3.0.0をインストールします。もしflask>=2.0.0がプロジェクトの依存関係であれば、flask 3.0.0のみが使用されます。これは重要です。たとえば、テストを実行する際に、プロジェクトが実際にその宣言された下限であるflask 2.0.0と互換性があるかどうかを確認しないからです。

With --resolution lowest, uv will install the lowest possible version for all dependencies, both direct and indirect (transitive). Alternatively, --resolution lowest-direct will use the lowest compatible versions for all direct dependencies, while using the latest compatible versions for all other dependencies. uv will always use the latest versions for build dependencies.--resolution lowestを使用すると、uvはすべての依存関係（直接および間接（推移的））に対して可能な限り低いバージョンをインストールします。あるいは、--resolution lowest-directはすべての直接依存関係に対して互換性のある最低バージョンを使用し、他のすべての依存関係には最新の互換性のあるバージョンを使用します。uvは常にビルド依存関係に対して最新のバージョンを使用します。

For example, given the following requirements.in file:たとえば、次のrequirements.inファイルがあるとします：

requirements.in
flask>=2.0.0

Running uv pip compile requirements.in would produce the following requirements.txt file:uv pip compile requirements.inを実行すると、次のrequirements.txtファイルが生成されます：

requirements.txt
# This file was autogenerated by uv via the following command:
#    uv pip compile requirements.in
blinker==1.7.0
    # via flask
click==8.1.7
    # via flask
flask==3.0.0
itsdangerous==2.1.2
    # via flask
jinja2==3.1.2
    # via flask
markupsafe==2.1.3
    # via
    #   jinja2
    #   werkzeug
werkzeug==3.0.1
    # via flask

However, uv pip compile --resolution lowest requirements.in would instead produce:しかし、uv pip compile --resolution lowest requirements.inを実行すると、代わりに次のようになります：

requirements.in
# This file was autogenerated by uv via the following command:
#    uv pip compile requirements.in --resolution lowest
click==7.1.2
    # via flask
flask==2.0.0
itsdangerous==2.0.0
    # via flask
jinja2==3.0.0
    # via flask
markupsafe==2.0.0
    # via jinja2
werkzeug==2.0.0
    # via flask

When publishing libraries, it is recommended to separately run tests with --resolution lowest or --resolution lowest-direct in continuous integration to ensure compatibility with the declared lower bounds.ライブラリを公開する際には、互換性を確保するために、継続的インテグレーションで--resolution lowestまたは--resolution lowest-directを使用してテストを別々に実行することをお勧めします。

Pre-release handlingプレリリースの取り扱い

By default, uv will accept pre-release versions during dependency resolution in two cases:デフォルトでは、uvは依存関係の解決中にプレリリースバージョンを2つのケースで受け入れます：

  1. If the package is a direct dependency, and its version specifiers include a pre-release specifier (e.g., flask>=2.0.0rc1).パッケージが直接の依存関係であり、そのバージョンスペシファイアにプレリリーススペシファイアが含まれている場合 （例：flask>=2.0.0rc1）。
  2. If all published versions of a package are pre-releases.すべての公開されたバージョンがプレリリースである場合。

If dependency resolution fails due to a transitive pre-release, uv will prompt use of --prerelease allow to allow pre-releases for all dependencies.依存関係の解決が遷移的なプレリリースによって失敗した場合、uvは --prerelease allowの使用を促し、すべての依存関係に対してプレリリースを許可します。

Alternatively, the transitive dependency can be added as a constraint or direct dependency (i.e. in requirements.in or pyproject.toml) with a pre-release version specifier (e.g., flask>=2.0.0rc1) to opt in to pre-release support for that specific dependency.あるいは、遷移的依存関係を制約または 直接の依存関係（すなわちrequirements.inまたはpyproject.toml内）としてプレリリースバージョン スペシファイア（例：flask>=2.0.0rc1）を使用して、その特定の依存関係に対するプレリリースサポートを選択することができます。

Pre-releases are notoriously difficult to model, and are a frequent source of bugs in other packaging tools. uv's pre-release handling is intentionally limited and requires user opt-in for pre-releases to ensure correctness.プレリリースは 非常に難しいとされており、他のパッケージングツールにおけるバグの頻繁な原因となります。uvのプレリリースの取り扱いは 意図的に制限されており、正確性を確保するためにプレリリースのユーザーオプトインが必要です。

For more details, see Pre-release compatibility.詳細については、 プレリリースの互換性を参照してください。

Multi-version resolutionマルチバージョン解決

During universal resolution, a package may be listed multiple times with different versions or URLs within the same lockfile, since different versions may be needed for different platforms or Python versions.ユニバーサル解決中、パッケージは同じロックファイル内で異なるバージョンやURLで複数回リストされることがあります。 異なるプラットフォームやPythonバージョンに対して異なるバージョンが必要な場合があるためです。

The --fork-strategy setting can be used to control how uv trades off between (1) minimizing the number of selected versions and (2) selecting the latest-possible version for each platform. The former leads to greater consistency across platforms, while the latter leads to use of newer package versions where possible.--fork-strategy 設定は、uvが (1) 選択されたバージョンの数を最小限に抑えることと (2) 各プラットフォームに対して可能な限り最新のバージョンを選択することの間でどのようにトレードオフするかを制御するために使用できます。前者はプラットフォーム間の一貫性を高め、後者は可能な限り新しいパッケージバージョンの使用を促します。

By default (--fork-strategy requires-python), uv will optimize for selecting the latest version of each package for each supported Python version, while minimizing the number of selected versions across platforms.デフォルトでは (--fork-strategy requires-python)、uvは各サポートされているPythonバージョンに対して各パッケージの最新バージョンを選択することを最適化し、プラットフォーム間で選択されたバージョンの数を最小限に抑えます。

For example, when resolving numpy with a Python requirement of >=3.8, uv would select the following versions:例えば、numpy を Python 要件 >=3.8 で解決する場合、uvは以下のバージョンを選択します：

numpy==1.24.4 ; python_version == "3.8"
numpy==2.0.2 ; python_version == "3.9"
numpy==2.2.0 ; python_version >= "3.10"

This resolution reflects the fact that NumPy 2.2.0 and later require at least Python 3.10, while earlier versions are compatible with Python 3.8 and 3.9.この解決は、NumPy 2.2.0 以降が少なくとも Python 3.10 を必要とし、以前のバージョンが Python 3.8 および 3.9 と互換性があるという事実を反映しています。

Under --fork-strategy fewest, uv will instead minimize the number of selected versions for each package, preferring older versions that are compatible with a wider range of supported Python versions or platforms.--fork-strategy fewest の下では、uvは各パッケージの選択されたバージョンの数を最小限に抑え、より広範囲のサポートされているPythonバージョンまたはプラットフォームと互換性のある古いバージョンを優先します。

For example, when in the scenario above, uv would select numpy==1.24.4 for all Python versions, rather than upgrading to numpy==2.0.2 for Python 3.9 and numpy==2.2.0 for Python 3.10 and later.例えば、上記のシナリオでは、uvはすべてのPythonバージョンに対して numpy==1.24.4 を選択し、Python 3.9 のために numpy==2.0.2 にアップグレードしたり、Python 3.10 およびそれ以降のために numpy==2.2.0 を選択したりしません。

Dependency constraints依存関係の制約

Like pip, uv supports constraint files (--constraint constraints.txt) which narrow the set of acceptable versions for the given packages. Constraint files are similar to requirements files, but being listed as a constraint alone will not cause a package to be included to the resolution. Instead, constraints only take effect if a requested package is already pulled in as a direct or transitive dependency. Constraints are useful for reducing the range of available versions for a transitive dependency. They can also be used to keep a resolution in sync with some other set of resolved versions, regardless of which packages are overlapping between the two.pipと同様に、uvは制約ファイル (--constraint constraints.txt) をサポートしており、指定されたパッケージの受け入れ可能なバージョンのセットを絞り込みます。制約ファイルは要件ファイルに似ていますが、制約としてリストされるだけではパッケージが解決に含まれることはありません。代わりに、制約は要求されたパッケージがすでに直接または間接的な依存関係として取り込まれている場合にのみ効果を発揮します。制約は、間接的な依存関係の利用可能なバージョンの範囲を減らすのに役立ちます。また、どのパッケージが2つの間で重複しているかに関係なく、他の解決されたバージョンのセットと解決を同期させるためにも使用できます。

Dependency overrides依存関係のオーバーライド

Dependency overrides allow bypassing unsuccessful or undesirable resolutions by overriding a package's declared dependencies. Overrides are a useful last resort for cases in which you know that a dependency is compatible with a certain version of a package, despite the metadata indicating otherwise.依存関係のオーバーライドは、パッケージの宣言された依存関係をオーバーライドすることによって、失敗したり望ましくない解決を回避することを可能にします。オーバーライドは、メタデータが異なることを示しているにもかかわらず、特定のバージョンのパッケージと互換性があることを知っている場合の有用な最後の手段です。

For example, if a transitive dependency declares the requirement pydantic>=1.0,<2.0, but does work with pydantic>=2.0, the user can override the declared dependency by including pydantic>=1.0,<3 in the overrides, thereby allowing the resolver to choose a newer version of pydantic.例えば、ある推移的依存関係がpydantic>=1.0,<2.0という要件を宣言しているが、実際には pydantic>=2.0でも動作する場合、ユーザーはオーバーライドにpydantic>=1.0,<3を含めることで、宣言された依存関係を上書きでき、これによりリゾルバは新しいバージョンのpydanticを選択できるようになります。

Concretely, if pydantic>=1.0,<3 is included as an override, uv will ignore all declared requirements on pydantic, replacing them with the override. In the above example, the pydantic>=1.0,<2.0 requirement would be ignored completely, and would instead be replaced with pydantic>=1.0,<3.具体的には、pydantic>=1.0,<3がオーバーライドとして含まれると、uvはpydanticに対するすべての宣言された要件を無視し、それらをオーバーライドで置き換えます。上記の例では、pydantic>=1.0,<2.0の要件は完全に無視され、代わりにpydantic>=1.0,<3に置き換えられます。

While constraints can only reduce the set of acceptable versions for a package, overrides can expand the set of acceptable versions, providing an escape hatch for erroneous upper version bounds. As with constraints, overrides do not add a dependency on the package and only take effect if the package is requested in a direct or transitive dependency.制約はパッケージの受け入れ可能なバージョンのセットを減少させることしかできませんが、オーバーライドは受け入れ可能なバージョンのセットを拡大させることができ、誤った上限バージョン境界からの逃げ道を提供します。制約と同様に、オーバーライドはパッケージへの依存関係を追加せず、パッケージが直接または推移的な依存関係で要求された場合にのみ効果を発揮します。

In a pyproject.toml, use tool.uv.override-dependencies to define a list of overrides. In the pip-compatible interface, the --override option can be used to pass files with the same format as constraints files.pyproject.tomlでは、tool.uv.override-dependenciesを使用してオーバーライドのリストを定義します。pip互換インターフェースでは、--overrideオプションを使用して、制約ファイルと同じ形式のファイルを渡すことができます。

If multiple overrides are provided for the same package, they must be differentiated with markers. If a package has a dependency with a marker, it is replaced unconditionally when using overrides — it does not matter if the marker evaluates to true or false.同じパッケージに対して複数のオーバーライドが提供される場合、それらはマーカーで区別する必要があります。パッケージがマーカーを持つ依存関係を持つ場合、オーバーライドを使用する際には無条件に置き換えられます — マーカーが真または偽に評価されるかどうかは関係ありません。

Dependency metadata依存関係メタデータ

During resolution, uv needs to resolve the metadata for each package it encounters, in order to determine its dependencies. This metadata is often available as a static file in the package index; however, for packages that only provide source distributions, the metadata may not be available upfront.解決中、uvは出会った各パッケージのメタデータを解決する必要があり、その依存関係を特定します。このメタデータは、パッケージインデックスの静的ファイルとして利用可能なことが多いですが、ソース配布のみを提供するパッケージの場合、メタデータが事前に利用できないことがあります。

In such cases, uv has to build the package to determine its metadata (e.g., by invoking setup.py). This can introduce a performance penalty during resolution. Further, it imposes the requirement that the package can be built on all platforms, which may not be true.そのような場合、uvはメタデータを特定するためにパッケージをビルドする必要があります（例：setup.pyを呼び出すことによって）。これにより、解決中にパフォーマンスのペナルティが発生する可能性があります。さらに、すべてのプラットフォームでパッケージをビルドできるという要件が課されますが、これは必ずしも真ではないかもしれません。

For example, you may have a package that should only be built and installed on Linux, but doesn't build successfully on macOS or Windows. While uv can construct a perfectly valid lockfile for this scenario, doing so would require building the package, which would fail on non-Linux platforms.例えば、Linuxでのみビルドおよびインストールされるべきパッケージがあり、macOSやWindowsでは正常にビルドされない場合があります。uvはこのシナリオに対して完全に有効なロックファイルを構築できますが、そうするためにはパッケージをビルドする必要があり、これは非Linuxプラットフォームでは失敗します。

The tool.uv.dependency-metadata table can be used to provide static metadata for such dependencies upfront, thereby allowing uv to skip the build step and use the provided metadata instead.tool.uv.dependency-metadataテーブルを使用して、そのような依存関係の静的メタデータを事前に提供することができ、これによりuvはビルドステップをスキップし、提供されたメタデータを使用できるようになります。

For example, to provide metadata for chumpy upfront, include its dependency-metadata in the pyproject.toml:chumpyのメタデータを事前に提供するためには、そのdependency-metadataを pyproject.tomlに含めます:

[[tool.uv.dependency-metadata]]
name = "chumpy"
version = "0.70"
requires-dist = ["numpy>=1.8.1", "scipy>=0.13.0", "six>=1.11.0"]

These declarations are intended for cases in which a package does not declare static metadata upfront, though they are also useful for packages that require disabling build isolation In such cases, it may be easier to declare the package metadata upfront, rather than creating a custom build environment prior to resolving the package.これらの宣言は、パッケージが事前に静的メタデータを宣言しない場合に使用されることを意図していますが、 ビルドの隔離を無効にする必要があるパッケージにも役立ちます。 そのような場合、パッケージの解決前にカスタムビルド環境を作成するよりも、 パッケージメタデータを事前に宣言する方が簡単かもしれません。

For example, past versions of flash-attn did not declare static metadata. By declaring metadata for flash-attn upfront, uv can resolve flash-attn without building the package from source (which itself requires installing torch):例えば、過去のflash-attnのバージョンは静的メタデータを宣言していませんでした。 flash-attnのメタデータを事前に宣言することで、uvはソースからパッケージをビルドすることなくflash-attnを解決できます （それ自体がtorchのインストールを必要とします）:

[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = ["flash-attn"]

[tool.uv.sources]
flash-attn = { git = "https://github.com/Dao-AILab/flash-attention", tag = "v2.6.3" }

[[tool.uv.dependency-metadata]]
name = "flash-attn"
version = "2.6.3"
requires-dist = ["torch", "einops"]

Like dependency overrides, tool.uv.dependency-metadata can also be used for cases in which a package's metadata is incorrect or incomplete, or when a package is not available in the package index. While dependency overrides allow overriding the allowed versions of a package globally, metadata overrides allow overriding the declared metadata of a specific package.依存関係のオーバーライドと同様に、tool.uv.dependency-metadataは、 パッケージのメタデータが不正確または不完全である場合や、パッケージがパッケージインデックスに存在しない場合にも使用できます。 依存関係のオーバーライドはパッケージの許可されたバージョンをグローバルにオーバーライドすることを可能にしますが、 メタデータのオーバーライドは特定のパッケージの宣言されたメタデータをオーバーライドすることを可能にします。

Note注意

The version field in tool.uv.dependency-metadata is optional for registry-based dependencies (when omitted, uv will assume the metadata applies to all versions of the package), but required for direct URL dependencies (like Git dependencies).tool.uv.dependency-metadataのversionフィールドは、レジストリベースの依存関係に対してはオプションですが（省略した場合、uvはメタデータがパッケージのすべてのバージョンに適用されると仮定します）、直接URL依存関係（Git依存関係など）には必須です。

Entries in the tool.uv.dependency-metadata table follow the Metadata 2.3 specification, though only name, version, requires-dist, requires-python, and provides-extra are read by uv. The version field is also considered optional. If omitted, the metadata will be used for all versions of the specified package.tool.uv.dependency-metadataテーブルのエントリは、 Metadata 2.3仕様に従いますが、 name、version、requires-dist、requires-python、およびprovides-extraのみが uvによって読み取られます。versionフィールドはオプションと見なされます。 省略された場合、メタデータは指定されたパッケージのすべてのバージョンに使用されます。

Conflicting dependencies依存関係の競合

uv requires that all dependencies declared by a project are compatible with each other and resolves all dependencies together when creating the lockfile. This includes project dependencies, optional dependencies ("extras"), and dependency groups (development dependencies).uvは、プロジェクトによって宣言されたすべての依存関係が互換性があることを要求し、 ロックファイルを作成する際にすべての依存関係を一緒に解決します。 これにはプロジェクト依存関係、オプション依存関係（"extras"）、および依存関係グループ（開発依存関係）が含まれます。

If dependencies declared in one extra are not compatible with those in another extra, uv will fail to resolve the requirements of the project with an error. For example, consider two sets of optional dependencies that conflict with one another:1つのextraで宣言された依存関係が別のextraの依存関係と互換性がない場合、 uvはプロジェクトの要件を解決できず、エラーが発生します。 例えば、互いに競合する2つのセットのオプション依存関係を考えてみましょう:

pyproject.toml
[project.optional-dependencies]
extra1 = ["numpy==2.1.2"]
extra2 = ["numpy==2.0.0"]

If you run uv lock with the above dependencies, resolution will fail:上記の依存関係でuv lockを実行すると、解決に失敗します:

$ uv lock
  x No solution found when resolving dependencies:
  `-> Because myproject[extra2] depends on numpy==2.0.0 and myproject[extra1] depends on numpy==2.1.2, we can conclude that myproject[extra1] and
      myproject[extra2] are incompatible.
      And because your project requires myproject[extra1] and myproject[extra2], we can conclude that your projects's requirements are unsatisfiable.

To work around this, uv supports explicit declaration of conflicts. If you specify that extra1 and extra2 are conflicting, uv will resolve them separately. Specify conflicts in the tool.uv section:これを回避するために、uvは競合の明示的な宣言をサポートしています。 extra1とextra2が競合していることを指定すると、uvはそれらを別々に解決します。 競合をtool.uvセクションに指定します:

pyproject.toml
[tool.uv]
conflicts = [
    [
      { extra = "extra1" },
      { extra = "extra2" },
    ],
]

Now, running uv lock will succeed. However, now you cannot install both extra1 and extra2 at the same time:これで、uv lockを実行すると成功します。ただし、今はextra1とextra2を同時にインストールすることはできません:

$ uv sync --extra extra1 --extra extra2
Resolved 3 packages in 14ms
error: extra `extra1`, extra `extra2` are incompatible with the declared conflicts: {`myproject[extra1]`, `myproject[extra2]`}

This error occurs because installing both extra1 and extra2 would result in installing two different versions of a package into the same environment.このエラーは、extra1とextra2の両方をインストールすると、同じ環境に異なるバージョンのパッケージがインストールされるために発生します。

The above strategy for dealing with conflicting optional dependencies also works with dependency groups:競合するオプション依存関係に対処するための上記の戦略は、依存関係グループにも適用されます：

pyproject.toml
[dependency-groups]
group1 = ["numpy==2.1.2"]
group2 = ["numpy==2.0.0"]

[tool.uv]
conflicts = [
    [
      { group = "group1" },
      { group = "group2" },
    ],
]

The only difference from conflicting extras is that you need to use the group key instead of extra.競合するエクストラとの唯一の違いは、extraの代わりにgroupキーを使用する必要があることです。

When using a workspace with multiple projects, the same restrictions apply — uv requires all workspace members to be compatible with each other. Similarly, conflicts can be declared across workspace members.複数のプロジェクトを持つワークスペースを使用する場合、同じ制限が適用されます — uvはすべてのワークスペースメンバーが互換性を持つことを要求します。同様に、ワークスペースメンバー間で競合を宣言することもできます。

For example, consider the following workspace:例えば、次のワークスペースを考えてみてください：

member1/pyproject.toml
[project]
name = "member1"

[project.optional-dependencies]
extra1 = ["numpy==2.1.2"]
member2/pyproject.toml
[project]
name = "member2"

[project.optional-dependencies]
extra2 = ["numpy==2.0.0"]

To declare a conflict between extras in these different workspace members, use the package key:これらの異なるワークスペースメンバー間でエクストラの競合を宣言するには、packageキーを使用します：

pyproject.toml
[tool.uv]
conflicts = [
    [
      { package = "member1", extra = "extra1" },
      { package = "member2", extra = "extra2" },
    ],
]

It's also possible for the project dependencies (i.e., project.dependencies) of one workspace member to conflict with the extra of another member, for example:あるワークスペースメンバーのプロジェクト依存関係（すなわち、project.dependencies）が別のメンバーのエクストラと競合することも可能です。例えば：

member1/pyproject.toml
[project]
name = "member1"
dependencies = ["numpy==2.1.2"]
member2/pyproject.toml
[project]
name = "member2"

[project.optional-dependencies]
extra2 = ["numpy==2.0.0"]

This conflict can also be declared using the package key:この競合もpackageキーを使用して宣言できます：

pyproject.toml
[tool.uv]
conflicts = [
    [
      { package = "member1" },
      { package = "member2", extra = "extra2" },
    ],
]

Similarly, it's possible for some workspace members to have conflicting project dependencies:同様に、一部のワークスペースメンバーが競合するプロジェクト依存関係を持つことも可能です：

member1/pyproject.toml
[project]
name = "member1"
dependencies = ["numpy==2.1.2"]
member2/pyproject.toml
[project]
name = "member2"
dependencies = ["numpy==2.0.0"]

This conflict can also be declared using the package key:この競合もpackageキーを使用して宣言できます：

pyproject.toml
[tool.uv]
conflicts = [
    [
      { package = "member1" },
      { package = "member2" },
    ],
]

These workspace members will not be installable together, e.g., the workspace root cannot define:これらのワークスペースメンバーは一緒にインストールできません。例えば、ワークスペースのルートは以下を定義できません：

pyproject.toml
[project]
name = "root"
dependencies = ["member1", "member2"]

Lower bounds下限

By default, uv add adds lower bounds to dependencies and, when using uv to manage projects, uv will warn if direct dependencies don't have lower bound.デフォルトでは、uv addは依存関係に下限を追加します。また、プロジェクトを管理するためにuvを使用する場合、直接の依存関係に下限がないと警告が表示されます。

Lower bounds are not critical in the "happy path", but they are important for cases where there are dependency conflicts. For example, consider a project that requires two packages and those packages have conflicting dependencies. The resolver needs to check all combinations of all versions within the constraints for the two packages — if all of them conflict, an error is reported because the dependencies are not satisfiable. If there are no lower bounds, the resolver can (and often will) backtrack down to the oldest version of a package. This isn't only problematic because it's slow, the old version of the package often fails to build, or the resolver can end up picking a version that's old enough that it doesn't depend on the conflicting package, but also doesn't work with your code.下限は「ハッピーパス」では重要ではありませんが、依存関係の競合がある場合には重要です。例えば、2つのパッケージを必要とするプロジェクトを考えてみてください。これらのパッケージには競合する依存関係があります。リゾルバは、2つのパッケージの制約内のすべてのバージョンのすべての組み合わせをチェックする必要があります。すべてが競合する場合、依存関係が満たされないためエラーが報告されます。下限がない場合、リゾルバは（しばしば）パッケージの最も古いバージョンにバックトラックすることができます。これは遅いだけでなく、古いバージョンのパッケージはビルドに失敗することが多く、リゾルバは競合するパッケージに依存しない古すぎるバージョンを選択することになりますが、それはあなたのコードともうまく動作しません。

Lower bounds are particularly critical when writing a library. It's important to declare the lowest version for each dependency that your library works with, and to validate that the bounds are correct — testing with --resolution lowest or --resolution lowest-direct. Otherwise, a user may receive an old, incompatible version of one of your library's dependencies and the library will fail with an unexpected error.下限はライブラリを書くときに特に重要です。ライブラリが動作する各依存関係の最低バージョンを宣言し、下限が正しいことを検証することが重要です — --resolution lowestまたは--resolution lowest-directを使用してテストします。そうしないと、ユーザーはライブラリの依存関係の古くて互換性のないバージョンを受け取り、ライブラリは予期しないエラーで失敗します。

Reproducible resolutions再現可能な解決策

uv supports an --exclude-newer option to limit resolution to distributions published before a specific date, allowing reproduction of installations regardless of new package releases. The date may be specified as an RFC 3339 timestamp (e.g., 2006-12-02T02:07:43Z) or a local date in the same format (e.g., 2006-12-02) in your system's configured time zone.uvは、特定の日付以前に公開された配布物に制限するための--exclude-newerオプションをサポートしており、新しいパッケージのリリースに関係なくインストールの再現を可能にします。日付はRFC 3339タイムスタンプ（例：2006-12-02T02:07:43Z）またはシステムの設定されたタイムゾーンでの同じ形式のローカル日付（例：2006-12-02）として指定できます。

Note the package index must support the upload-time field as specified in PEP 700. If the field is not present for a given distribution, the distribution will be treated as unavailable. PyPI provides upload-time for all packages.パッケージインデックスは、upload-timeフィールドをPEP 700に従ってサポートする必要があります。特定の配布物に対してフィールドが存在しない場合、その配布物は利用できないものとして扱われます。PyPIはすべてのパッケージに対してupload-timeを提供しています。

To ensure reproducibility, messages for unsatisfiable resolutions will not mention that distributions were excluded due to the --exclude-newer flag — newer distributions will be treated as if they do not exist.再現性を確保するために、満たされない解決策に関するメッセージには、--exclude-newerフラグによって配布物が除外されたことは言及されません — 新しい配布物は存在しないかのように扱われます。

Note注意

The --exclude-newer option is only applied to packages that are read from a registry (as opposed to, e.g., Git dependencies). Further, when using the uv pip interface, uv will not downgrade previously installed packages unless the --reinstall flag is provided, in which case uv will perform a new resolution.--exclude-newerオプションは、レジストリから読み取られるパッケージにのみ適用されます（例えば、Git依存関係とは対照的に）。さらに、uv pipインターフェースを使用する場合、--reinstallフラグが提供されない限り、uvは以前にインストールされたパッケージをダウングレードしません。この場合、uvは新しい解決を行います。

Source distributionソース配布

PEP 625 specifies that packages must distribute source distributions as gzip tarball (.tar.gz) archives. Prior to this specification, other archive formats, which need to be supported for backward compatibility, were also allowed. uv supports reading and extracting archives in the following formats:PEP 625 は、パッケージがソース配布を gzip tarball (.tar.gz) アーカイブとして配布する必要があることを規定しています。この仕様以前は、後方互換性を保つために他のアーカイブ形式も許可されていました。uv は以下の形式のアーカイブの読み取りと抽出をサポートしています：

  • gzip tarball (.tar.gz, .tgz)gzip tarball (.tar.gz, .tgz)
  • bzip2 tarball (.tar.bz2, .tbz)bzip2 tarball (.tar.bz2, .tbz)
  • xz tarball (.tar.xz, .txz)xz tarball (.tar.xz, .txz)
  • zstd tarball (.tar.zst)zstd tarball (.tar.zst)
  • lzip tarball (.tar.lz)lzip tarball (.tar.lz)
  • lzma tarball (.tar.lzma)lzma tarball (.tar.lzma)
  • zip (.zip)zip (.zip)

Lockfile versioningロックファイルのバージョニング

The uv.lock file uses a versioned schema. The schema version is included in the version field of the lockfile.uv.lockファイルはバージョン管理されたスキーマを使用します。スキーマのバージョンはロックファイルのversionフィールドに含まれています。

Any given version of uv can read and write lockfiles with the same schema version, but will reject lockfiles with a greater schema version. For example, if your uv version supports schema v1, uv lock will error if it encounters an existing lockfile with schema v2.特定のバージョンのuvは、同じスキーマバージョンのロックファイルを読み書きできますが、より大きなスキーマバージョンのロックファイルは拒否します。たとえば、あなたのuvバージョンがスキーマv1をサポートしている場合、uv lockはスキーマv2の既存のロックファイルに遭遇するとエラーになります。

uv versions that support schema v2 may be able to read lockfiles with schema v1 if the schema update was backwards-compatible. However, this is not guaranteed, and uv may exit with an error if it encounters a lockfile with an outdated schema version.スキーマv2をサポートするuvバージョンは、スキーマ更新が後方互換性がある場合、スキーマv1のロックファイルを読み取ることができるかもしれません。ただし、これは保証されておらず、uvは古いスキーマバージョンのロックファイルに遭遇するとエラーで終了する可能性があります。

The schema version is considered part of the public API, and so is only bumped in minor releases, as a breaking change (see Versioning). As such, all uv patch versions within a given minor uv release are guaranteed to have full lockfile compatibility. In other words, lockfiles may only be rejected across minor releases.スキーマバージョンは公開APIの一部と見なされるため、マイナーリリースでのみバンプされ、破壊的変更として扱われます（詳細はバージョニングを参照）。そのため、特定のマイナーuvリリース内のすべてのuvパッチバージョンは、完全なロックファイル互換性を持つことが保証されています。言い換えれば、ロックファイルはマイナーリリースを跨いでのみ拒否される可能性があります。

The revision field of the lockfile is used to track backwards compatible changes to the lockfile. For example, adding a new field to distributions. Changes to the revision will not cause older versions of uv to error.ロックファイルのrevisionフィールドは、ロックファイルへの後方互換性のある変更を追跡するために使用されます。たとえば、配布に新しいフィールドを追加することです。リビジョンの変更は、古いバージョンのuvにエラーを引き起こすことはありません。

Learn more詳細を学ぶ

For more details about the internals of the resolver, see the resolver reference documentation.リゾルバの内部に関する詳細については、リゾルバリファレンスドキュメントを参照してください。