Compatibility with `pip` and `pip-tools`Compatibility with `pip` and `pip-tools`

uv is designed as a drop-in replacement for common pip and pip-tools workflows.uvは一般的な pip および pip-tools ワークフローのドロップイン置き換えとして設計されています。

Informally, the intent is such that existing pip and pip-tools users can switch to uv without making meaningful changes to their packaging workflows; and, in most cases, swapping out pip install for uv pip install should "just work".非公式には、既存の pip および pip-tools ユーザーが、パッケージングワークフローに意味のある変更を加えることなく uv に切り替えられることを意図しています。そして、ほとんどの場合、pip install を uv pip install に置き換えるだけで「うまくいく」はずです。

However, uv is not intended to be an exact clone of pip, and the further you stray from common pip workflows, the more likely you are to encounter differences in behavior. In some cases, those differences may be known and intentional; in others, they may be the result of implementation details; and in others, they may be bugs.しかし、uv は 正確な クローンとして意図されているわけではなく、一般的な pip ワークフローから逸脱すればするほど、動作の違いに遭遇する可能性が高くなります。場合によっては、それらの違いは知られていて意図的なものであり、他の場合では実装の詳細の結果であり、また他の場合ではバグである可能性があります。

This document outlines the known differences between uv and pip, along with rationale, workarounds, and a statement of intent for compatibility in the future.この文書では、uv と pip の間の既知の違いを概説し、理由、回避策、および将来の互換性に関する意図の声明を示します。

Configuration files and environment variables設定ファイルと環境変数

uv does not read configuration files or environment variables that are specific to pip, like pip.conf or PIP_INDEX_URL.uv は、pip に特有の設定ファイルや環境変数（pip.conf や PIP_INDEX_URL など）を読み込みません。

Reading configuration files and environment variables intended for other tools has a number of drawbacks:他のツール向けに意図された設定ファイルや環境変数を読み込むことには、いくつかの欠点があります：

It requires bug-for-bug compatibility with the target tool, since users end up relying on bugs in the format, the parser, etc.それは、ユーザーがフォーマットやパーサーなどのバグに依存することになるため、ターゲットツールとのバグ互換性を必要とします。
If the target tool changes the format in some way, uv is then locked-in to changing it in equivalent ways.ターゲットツールが何らかの方法でフォーマットを変更した場合、uvはそれに応じて変更することにロックインされます。
If that configuration is versioned in some way, uv would need to know which version of the target tool the user is expecting to use.その設定が何らかの方法でバージョン管理されている場合、uvはユーザーが使用することを期待しているターゲットツールのどのバージョンを知る必要があります。
It prevents uv from introducing any settings or configuration that don't exist in the target tool, since otherwise pip.conf (or similar) would no longer be usable with pip.それは、uvがターゲットツールに存在しない設定や構成を導入することを妨げます。そうでなければ、pip.conf（または類似のもの）がpipで使用できなくなります。
It can lead to user confusion, since uv would be reading settings that don't actually affect its behavior, and many users may not expect uv to read configuration files intended for other tools.それはユーザーの混乱を招く可能性があります。なぜなら、uvは実際にはその動作に影響を与えない設定を読み込むことになり、多くのユーザーはuvが他のツール向けの設定ファイルを読み込むことを期待していないかもしれないからです。

Instead, uv supports its own environment variables, like UV_INDEX_URL. uv also supports persistent configuration in a uv.toml file or a [tool.uv.pip] section of pyproject.toml. For more information, see Configuration files.その代わりに、uvはUV_INDEX_URLのような独自の環境変数をサポートしています。uvはまた、uv.tomlファイルやpyproject.tomlの[tool.uv.pip]セクションでの永続的な設定をサポートしています。詳細については、設定ファイルを参照してください。

Pre-release compatibilityプレリリースの互換性

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

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

If dependency resolution fails due to a transitive pre-release, uv will prompt the user to re-run with --prerelease allow, to allow pre-releases for all dependencies.依存関係の解決が遷移的なプレリリースのために失敗した場合、uvはユーザーに--prerelease allowを使用して再実行するように促し、すべての依存関係に対してプレリリースを許可します。

Alternatively, you can add the transitive dependency to your requirements.in file with pre-release specifier (e.g., flask>=2.0.0rc1) to opt in to pre-release support for that specific dependency.あるいは、requirements.inファイルに前リリース指定子（例：flask>=2.0.0rc1）を追加することで、その特定の依存関係に対する前リリースサポートを選択することができます。

In sum, uv needs to know upfront whether the resolver should accept pre-releases for a given package. pip, meanwhile, may respect pre-release identifiers in transitive dependencies depending on the order in which the resolver encounters the relevant specifiers (#1641).要するに、uvは、解決者が特定のパッケージに対して前リリースを受け入れるべきかどうかを事前に知る必要があります。一方、pipは、解決者が関連する指定子に出会う順序に応じて、推移的依存関係における前リリース識別子を尊重する可能性があります（#1641）。

Pre-releases are notoriously difficult to model, and are a frequent source of bugs in packaging tools. Even pip, which is viewed as a reference implementation, has a number of open questions around pre-release handling (#12469, #12470, #40505, etc.). uv's pre-release handling is intentionally limited and intentionally requires user opt-in for pre-releases, to ensure correctness.前リリースは、非常に難しいモデルであり、パッケージングツールにおけるバグの頻繁な原因となります。参照実装と見なされるpipでさえ、前リリースの取り扱いに関していくつかの未解決の問題があります（#12469、#12470、#40505など）。uvの前リリースの取り扱いは意図的に制限されており、前リリースに対してユーザーの選択を意図的に要求します。これにより、正確性が確保されます。

In the future, uv may support pre-release identifiers in transitive dependencies. However, it's likely contingent on evolution in the Python packaging specifications. The existing PEPs do not cover "dependency resolution" and are instead focused on behavior for a single version specifier. As such, there are unresolved questions around the correct and intended behavior for pre-releases in the packaging ecosystem more broadly.将来的には、uvは推移的依存関係における前リリース識別子をサポートする可能性があります。ただし、これはPythonパッケージング仕様の進化に依存する可能性が高いです。既存のPEPは、「依存関係の解決」をカバーしていませんが、単一のバージョン指定子の動作に焦点を当てています。そのため、パッケージングエコシステム全体における前リリースの正しい意図された動作に関しては未解決の問題があります。

Packages that exist on multiple indexes複数のインデックスに存在するパッケージ

In both uv and pip, users can specify multiple package indexes from which to search for the available versions of a given package. However, uv and pip differ in how they handle packages that exist on multiple indexes.uvとpipの両方で、ユーザーは特定のパッケージの利用可能なバージョンを検索するために複数のパッケージインデックスを指定できます。ただし、uvとpipは、複数のインデックスに存在するパッケージの取り扱いにおいて異なります。

For example, imagine that a company publishes an internal version of requests on a private index (--extra-index-url), but also allows installing packages from PyPI by default. In this case, the private requests would conflict with the public requests on PyPI.例えば、ある企業がプライベートインデックスにrequestsの内部バージョンを公開し（--extra-index-url）、デフォルトでPyPIからパッケージをインストールすることを許可しているとします。この場合、プライベートなrequestsは、PyPI上の公開されたrequestsと衝突します。

When uv searches for a package across multiple indexes, it will iterate over the indexes in order (preferring the --extra-index-url over the default index), and stop searching as soon as it finds a match. This means that if a package exists on multiple indexes, uv will limit its candidate versions to those present in the first index that contains the package.uvが複数のインデックスでパッケージを検索する際、インデックスを順番に反復処理し（--extra-index-urlをデフォルトインデックスより優先し）、一致するものを見つけた時点で検索を停止します。これにより、パッケージが複数のインデックスに存在する場合、uvはそのパッケージを含む最初のインデックスに存在する候補バージョンに制限します。

pip, meanwhile, will combine the candidate versions from all indexes, and select the best version from the combined set, though it makes no guarantees around the order in which it searches indexes, and expects that packages are unique up to name and version, even across indexes.一方、pipはすべてのインデックスから候補バージョンを組み合わせ、結合されたセットから最良のバージョンを選択しますが、インデックスを検索する順序に関しては保証はありません。また、インデックス間であっても、パッケージは名前とバージョンに基づいて一意であることを期待しています。

uv's behavior is such that if a package exists on an internal index, it should always be installed from the internal index, and never from PyPI. The intent is to prevent "dependency confusion" attacks, in which an attacker publishes a malicious package on PyPI with the same name as an internal package, thus causing the malicious package to be installed instead of the internal package. See, for example, the torchtriton attack from December 2022.uvの動作は、パッケージが内部インデックスに存在する場合、常に内部インデックスからインストールされ、決してPyPIからインストールされるべきではないというものです。この意図は、「依存関係の混乱」攻撃を防ぐことです。これは、攻撃者が内部パッケージと同じ名前の悪意のあるパッケージをPyPIに公開し、その結果、悪意のあるパッケージが内部パッケージの代わりにインストールされるというものです。例えば、2022年12月のtorchtriton攻撃を参照してください。

As of v0.1.39, users can opt in to pip-style behavior for multiple indexes via the --index-strategy command-line option, or the UV_INDEX_STRATEGY environment variable, which supports the following values:v0.1.39以降、ユーザーはpipスタイルの動作を複数のインデックスに対して選択できるようになりました。 --index-strategyコマンドラインオプションまたはUV_INDEX_STRATEGY環境変数を使用することで、以下の値をサポートしています：

first-index (default): Search for each package across all indexes, limiting the candidate versions to those present in the first index that contains the package, prioritizing the --extra-index-url indexes over the default index URL.first-index（デフォルト）：各パッケージをすべてのインデックスで検索し、候補バージョンをそのパッケージを含む最初のインデックスに存在するものに制限し、 --extra-index-urlインデックスをデフォルトのインデックスURLよりも優先します。
unsafe-first-match: Search for each package across all indexes, but prefer the first index with a compatible version, even if newer versions are available on other indexes.unsafe-first-match: すべてのインデックスで各パッケージを検索しますが、互換性のあるバージョンがある場合は最初のインデックスを優先します。たとえ他のインデックスに新しいバージョンがあってもです。
unsafe-best-match: Search for each package across all indexes, and select the best version from the combined set of candidate versions.unsafe-best-match: すべてのインデックスで各パッケージを検索し、候補バージョンの組み合わせから最適なバージョンを選択します。

While unsafe-best-match is the closest to pip's behavior, it exposes users to the risk of "dependency confusion" attacks.unsafe-best-matchはpipの動作に最も近いですが、ユーザーを「依存関係の混乱」攻撃のリスクにさらします。

uv also supports pinning packages to dedicated indexes (see: Indexes), such that a given package is always installed from a specific index.uvは、特定のインデックスにパッケージを固定することもサポートしています（参照： インデックス）、特定のパッケージが常に特定のインデックスからインストールされるようにします。

PEP 517 build isolationPEP 517ビルドアイソレーション

uv uses PEP 517 build isolation by default (akin to pip install --use-pep517), following pypa/build and in anticipation of pip defaulting to PEP 517 builds in the future (pypa/pip#9175).uvはデフォルトでPEP 517ビルドアイソレーションを使用します（pip install --use-pep517に似ています）、 pypa/buildに従い、将来的にpipがPEP 517ビルドをデフォルトにすることを見越しています（pypa/pip#9175）。

If a package fails to install due to a missing build-time dependency, try using a newer version of the package; if the problem persists, consider filing an issue with the package maintainer, requesting that they update the packaging setup to declare the correct PEP 517 build-time dependencies.パッケージがビルド時の依存関係が欠如しているためにインストールに失敗した場合は、パッケージの新しいバージョンを使用してみてください。問題が解決しない場合は、パッケージのメンテナーに問題を報告し、正しいPEP 517ビルド時の依存関係を宣言するようにパッケージの設定を更新するよう依頼してください。

As an escape hatch, you can preinstall a package's build dependencies, then run uv pip install with --no-build-isolation, as in:エスケープハッチとして、パッケージのビルド依存関係を事前にインストールし、次にuv pip install を--no-build-isolationオプションで実行できます。例：

uv pip install wheel && uv pip install --no-build-isolation biopython==1.77

For a list of packages that are known to fail under PEP 517 build isolation, see #2252.PEP 517ビルドアイソレーションの下で失敗することが知られているパッケージのリストについては、 #2252を参照してください。

Transitive URL dependencies推移的URL依存関係

While uv includes first-class support for URL dependencies (e.g., ruff @ https://...), it differs from pip in its handling of transitive URL dependencies in two ways.uvはURL依存関係（例：ruff @ https://...）に対してファーストクラスのサポートを提供していますが、推移的 URL依存関係の扱いにおいてpipとは2つの点で異なります。

First, uv makes the assumption that non-URL dependencies do not introduce URL dependencies into the resolution. In other words, it assumes that dependencies fetched from a registry do not themselves depend on URLs. If a non-URL dependency does introduce a URL dependency, uv will reject the URL dependency during resolution. (Note that PyPI does not allow published packages to depend on URL dependencies; other registries may be more permissive.)まず、uvは非URL依存関係が解決にURL依存関係を導入しないという仮定をしています。言い換えれば、レジストリから取得した依存関係は自らURLに依存しないと仮定しています。もし非URL依存関係がURL依存関係を導入する場合、uvは解決中にそのURL依存関係を拒否します。（PyPIは公開されたパッケージがURL依存関係に依存することを許可していないことに注意してください。他のレジストリはより寛容かもしれません。）

Second, if a constraint (--constraint) or override (--override) is defined using a direct URL dependency, and the constrained package has a direct URL dependency of its own, uv may reject that transitive direct URL dependency during resolution, if the URL isn't referenced elsewhere in the set of input requirements.次に、制約（--constraint）またはオーバーライド（--override）が直接URL依存関係を使用して定義されている場合、制約されたパッケージが独自の直接URL依存関係を持っていると、uvは解決中にその推移的な直接URL依存関係を拒否する可能性があります。そのURLが入力要件のセット内の他の場所で参照されていない場合です。

If uv rejects a transitive URL dependency, the best course of action is to provide the URL dependency as a direct dependency in the relevant pyproject.toml or requirement.in file, as the above constraints do not apply to direct dependencies.uvが推移的URL依存関係を拒否した場合、最善の対策は、関連するpyproject.tomlまたはrequirement.inファイルにURL依存関係を直接依存関係として提供することです。上記の制約は直接依存関係には適用されません。

Virtual environments by defaultデフォルトでの仮想環境

uv pip install and uv pip sync are designed to work with virtual environments by default.uv pip installおよびuv pip syncは、デフォルトで仮想環境と連携するように設計されています。

Specifically, uv will always install packages into the currently active virtual environment, or search for a virtual environment named .venv in the current directory or any parent directory (even if it is not activated).具体的には、uvは常に現在アクティブな仮想環境にパッケージをインストールするか、現在のディレクトリまたは親ディレクトリに.venvという名前の仮想環境を探します（たとえそれがアクティブでなくても）。

This differs from pip, which will install packages into a global environment if no virtual environment is active, and will not search for inactive virtual environments.これは、pipとは異なり、アクティブな仮想環境がない場合はグローバル環境にパッケージをインストールし、非アクティブな仮想環境を探さないからです。

In uv, you can install into non-virtual environments by providing a path to a Python executable via the --python /path/to/python option, or via the --system flag, which installs into the first Python interpreter found on the PATH, like pip.uvでは、--python /path/to/pythonオプションを介してPython実行可能ファイルへのパスを提供するか、--systemフラグを使用することで、非仮想環境にインストールできます。このフラグは、pipのようにPATH上で最初に見つかったPythonインタプリタにインストールします。

In other words, uv inverts the default, requiring explicit opt-in to installing into the system Python, which can lead to breakages and other complications, and should only be done in limited circumstances.言い換えれば、uvはデフォルトを反転させ、システムPythonにインストールするためには明示的なオプトインが必要です。これにより破損やその他の複雑さが生じる可能性があり、限られた状況でのみ行うべきです。

For more, see "Using arbitrary Python environments".詳細については、 "任意のPython環境の使用"を参照してください。

Resolution strategy解決戦略

For a given set of dependency specifiers, it's often the case that there is no single "correct" set of packages to install. Instead, there are many valid sets of packages that satisfy the specifiers.特定の依存関係指定子のセットに対して、インストールする「正しい」パッケージのセットは存在しないことがよくあります。代わりに、指定子を満たす有効なパッケージのセットが多数存在します。

Neither pip nor uv make any guarantees about the exact set of packages that will be installed; only that the resolution will be consistent, deterministic, and compliant with the specifiers. As such, in some cases, pip and uv will yield different resolutions; however, both resolutions should be equally valid.pipもuvも、インストールされるパッケージの正確なセットについては保証しません。指定子に対して、一貫性があり、決定論的で、準拠した解決が行われることのみが保証されます。そのため、場合によっては、pipとuvが異なる解決をもたらすことがありますが、両方の解決は同等に有効であるべきです。

For example, consider:例えば、次のような場合を考えてみましょう：

requirements.in

starlette
fastapi

At time of writing, the most recent starlette version is 0.37.2, and the most recent fastapi version is 0.110.0. However, fastapi==0.110.0 also depends on starlette, and introduces an upper bound: starlette>=0.36.3,<0.37.0.執筆時点で、最新のstarletteバージョンは0.37.2で、最新のfastapiバージョンは0.110.0です。しかし、fastapi==0.110.0はstarletteにも依存しており、上限を導入します：starlette>=0.36.3,<0.37.0。

If a resolver prioritizes including the most recent version of starlette, it would need to use an older version of fastapi that excludes the upper bound on starlette. In practice, this requires falling back to fastapi==0.1.17:もしリゾルバが最新のstarletteバージョンを含めることを優先する場合、starletteの上限を除外する古いバージョンのfastapiを使用する必要があります。実際には、fastapi==0.1.17にフォールバックする必要があります：

requirements.txt

# This file was autogenerated by uv via the following command:
#    uv pip compile requirements.in
annotated-types==0.6.0
    # via pydantic
anyio==4.3.0
    # via starlette
fastapi==0.1.17
idna==3.6
    # via anyio
pydantic==2.6.3
    # via fastapi
pydantic-core==2.16.3
    # via pydantic
sniffio==1.3.1
    # via anyio
starlette==0.37.2
    # via fastapi
typing-extensions==4.10.0
    # via
    #   pydantic
    #   pydantic-core

Alternatively, if a resolver prioritizes including the most recent version of fastapi, it would need to use an older version of starlette that satisfies the upper bound. In practice, this requires falling back to starlette==0.36.3:逆に、リゾルバが最新のfastapiバージョンを含めることを優先する場合、上限を満たす古いバージョンのstarletteを使用する必要があります。実際には、starlette==0.36.3にフォールバックする必要があります：

requirements.txt

# This file was autogenerated by uv via the following command:
#    uv pip compile requirements.in
annotated-types==0.6.0
    # via pydantic
anyio==4.3.0
    # via starlette
fastapi==0.110.0
idna==3.6
    # via anyio
pydantic==2.6.3
    # via fastapi
pydantic-core==2.16.3
    # via pydantic
sniffio==1.3.1
    # via anyio
starlette==0.36.3
    # via fastapi
typing-extensions==4.10.0
    # via
    #   fastapi
    #   pydantic
    #   pydantic-core

When uv resolutions differ from pip in undesirable ways, it's often a sign that the specifiers are too loose, and that the user should consider tightening them. For example, in the case of starlette and fastapi, the user could require fastapi>=0.110.0.uvの解決がpipと望ましくない方法で異なる場合、それはしばしば指定子が緩すぎることを示すサインであり、ユーザーはそれらを厳しくすることを検討すべきです。例えば、starletteとfastapiのケースでは、ユーザーはfastapi>=0.110.0を要求することができます。

`pip checkpip check`

At present, uv pip check will surface the following diagnostics:現在、uv pip checkは次の診断情報を表示します：

A package has no METADATA file, or the METADATA file can't be parsed.パッケージに METADATA ファイルがないか、METADATA ファイルを解析できません。
A package has a Requires-Python that doesn't match the Python version of the running interpreter.パッケージに、実行中のインタープリタのPythonバージョンと一致しない Requires-Python が含まれています。
A package has a dependency on a package that isn't installed.パッケージがインストールされていないパッケージに依存しています。
A package has a dependency on a package that's installed, but at an incompatible version.パッケージがインストールされているパッケージに依存していますが、互換性のないバージョンです。
Multiple versions of a package are installed in the virtual environment.仮想環境に複数のバージョンのパッケージがインストールされています。

In some cases, uv pip check will surface diagnostics that pip check does not, and vice versa. For example, unlike uv pip check, pip check will not warn when multiple versions of a package are installed in the current environment.場合によっては、uv pip check が pip check では表示されない診断情報を示すことがあります。その逆も然り。例えば、uv pip check とは異なり、pip check は現在の環境に複数のバージョンのパッケージがインストールされている場合に 警告しません。

`--user` and the `user` install scheme`--user` と `user` インストールスキーム

uv does not support the --user flag, which installs packages based on the user install scheme. Instead, we recommend the use of virtual environments to isolate package installations.uv は --user フラグをサポートしておらず、これは user インストールスキームに基づいてパッケージをインストールします。その代わりに、パッケージのインストールを隔離するために仮想環境の使用を推奨します。

Additionally, pip will fall back to the user install scheme if it detects that the user does not have write permissions to the target directory, as is the case on some systems when installing into the system Python. uv does not implement any such fallback.さらに、pip はユーザーがターゲットディレクトリへの書き込み権限を持っていないことを検出した場合、user インストールスキームにフォールバックします。これは、システムPythonにインストールする際に一部のシステムで発生します。uv はそのようなフォールバックを実装していません。

For more, see #2077.詳細については、#2077 を参照してください。

`--only-binary` enforcement`--only-binary` enforcement

The --only-binary argument is used to restrict installation to pre-built binary distributions. When --only-binary :all: is provided, both pip and uv will refuse to build source distributions from PyPI and other registries.--only-binary 引数は、インストールを事前にビルドされたバイナリ配布に制限するために使用されます。 --only-binary :all: が指定されると、pip と uv は PyPI や他のレジストリからソース配布をビルドすることを拒否します。

However, when a dependency is provided as a direct URL (e.g., uv pip install https://...), pip does not enforce --only-binary, and will build source distributions for all such packages.ただし、依存関係が直接 URL として提供される場合（例: uv pip install https://...）、pip は 強制しません --only-binary を、すべてのそのようなパッケージのソース配布をビルドします。

uv, meanwhile, does enforce --only-binary for direct URL dependencies, with one exception: given uv pip install https://... --only-binary flask, uv will build the source distribution at the given URL if it cannot infer the package name ahead of time, since uv can't determine whether the package is "allowed" in such cases without building its metadata.一方、uv は直接 URL 依存関係に対して 強制します --only-binary を、1つの例外を除いて: uv pip install https://... --only-binary flask が与えられた場合、uv はパッケージ名を事前に推測できない場合、指定された URL でソース配布をビルドします。なぜなら、uv はそのメタデータをビルドせずにパッケージが「許可されている」かどうかを判断できないからです。

Both pip and uv allow editables requirements to be built and installed even when --only-binary is provided. For example, uv pip install -e . --only-binary :all: is allowed.pip と uv の両方は、--only-binary が提供されている場合でも、編集可能な要件をビルドしてインストールすることを許可します。たとえば、uv pip install -e . --only-binary :all: は許可されています。

`--no-binary` enforcement`--no-binary` enforcement

The --no-binary argument is used to restrict installation to source distributions. When --no-binary is provided, uv will refuse to install pre-built binary distributions, but will reuse any binary distributions that are already present in the local cache.--no-binary 引数は、インストールをソース配布に制限するために使用されます。--no-binary が提供されると、uv は事前にビルドされたバイナリ配布のインストールを拒否しますが、すでにローカルキャッシュに存在する バイナリ配布は再利用します。

Additionally, and in contrast to pip, uv's resolver will still read metadata from pre-built binary distributions when --no-binary is provided.さらに、pip とは対照的に、uv のリゾルバは --no-binary が提供されている場合でも、事前にビルドされたバイナリ配布からメタデータを読み取ります。

`manylinux_compatible` enforcement`manylinux_compatible` enforcement

PEP 600 describes a mechanism through which Python distributors can opt out of manylinux compatibility by defining a manylinux_compatible function on the _manylinux standard library module.PEP 600 は、Python ディストリビュータが _manylinux 標準ライブラリモジュールに manylinux_compatible 関数を定義することで manylinux 互換性をオプトアウトできるメカニズムを説明しています。

uv respects manylinux_compatible, but only tests against the current glibc version, and applies the return value of manylinux_compatible globally.uvはmanylinux_compatibleを尊重しますが、現在のglibcバージョンに対してのみテストを行い、manylinux_compatibleの戻り値をグローバルに適用します。

In other words, if manylinux_compatible returns True, uv will treat the system as manylinux-compatible; if it returns False, uv will treat the system as manylinux-incompatible, without calling manylinux_compatible for every glibc version.言い換えれば、manylinux_compatibleがTrueを返す場合、uvはシステムをmanylinux互換と見なします; もしFalseを返す場合、uvはシステムをmanylinux非互換と見なし、すべてのglibcバージョンに対してmanylinux_compatibleを呼び出すことはありません。

This approach is not a complete implementation of the spec, but is compatible with common blanket manylinux_compatible implementations like no-manylinux:このアプローチは仕様の完全な実装ではありませんが、一般的な包括的manylinux_compatible実装（例えば、no-manylinux）と互換性があります。

from __future__ import annotations
manylinux1_compatible = False
manylinux2010_compatible = False
manylinux2014_compatible = False


def manylinux_compatible(*_, **__):  # PEP 600
    return False

Bytecode compilationバイトコードコンパイル

Unlike pip, uv does not compile .py files to .pyc files during installation by default (i.e., uv does not create or populate __pycache__ directories). To enable bytecode compilation during installs, pass the --compile-bytecode flag to uv pip install or uv pip sync, or set the UV_COMPILE_BYTECODE environment variable to 1.pipとは異なり、uvはデフォルトでインストール中に.pyファイルを.pycファイルにコンパイルしません（つまり、uvは__pycache__ディレクトリを作成またはポピュレートしません）。インストール中にバイトコードコンパイルを有効にするには、uv pip installまたはuv pip syncに--compile-bytecodeフラグを渡すか、UV_COMPILE_BYTECODE環境変数を1に設定します。

Skipping bytecode compilation can be undesirable in workflows; for example, we recommend enabling bytecode compilation in Docker builds to improve startup times (at the cost of increased build times).バイトコードコンパイルをスキップすることは、ワークフローにおいて望ましくない場合があります; 例えば、起動時間を改善するために、Dockerビルドでバイトコードコンパイルを有効にすることを推奨します（ビルド時間が増加する代償として）。

As bytecode compilation suppresses various warnings issued by the Python interpreter, in rare cases you may seen SyntaxWarning or DeprecationWarning messages when running Python code that was installed with uv that do not appear when using pip. These are valid warnings, but are typically hidden by the bytecode compilation process, and can either be ignored, fixed upstream, or similarly suppressed by enabling bytecode compilation in uv.バイトコードコンパイルはPythonインタープリタによって発行されるさまざまな警告を抑制するため、稀にuvでインストールされたPythonコードを実行する際に、pipを使用した場合には表示されないSyntaxWarningやDeprecationWarningメッセージが表示されることがあります。これらは有効な警告ですが、通常はバイトコードコンパイルプロセスによって隠され、無視するか、上流で修正するか、またはuvでバイトコードコンパイルを有効にすることで同様に抑制できます。

Strictness and spec enforcement厳密さと仕様の遵守

uv tends to be stricter than pip, and will often reject packages that pip would install. For example, uv rejects HTML indexes with invalid URL fragments (see: PEP 503), while pip will ignore such fragments.uvはpipよりも厳格であり、pipがインストールするパッケージを拒否することがよくあります。例えば、uvは無効なURLフラグメントを持つHTMLインデックスを拒否します（参照: PEP 503）、一方でpipはそのようなフラグメントを無視します。

In some cases, uv implements lenient behavior for popular packages that are known to have specific spec compliance issues.場合によっては、uvは特定の仕様遵守の問題が知られている人気パッケージに対して寛容な動作を実装しています。

If uv rejects a package that pip would install due to a spec violation, the best course of action is to first attempt to install a newer version of the package; and, if that fails, to report the issue to the package maintainer.もし uv が仕様違反のために pip がインストールしようとするパッケージを拒否した場合、最善の対処法はまずそのパッケージの新しいバージョンをインストールしようと試みることです。そして、それが失敗した場合は、パッケージのメンテナーに問題を報告してください。

`pip` command-line options and subcommands`pip` コマンドラインオプションとサブコマンド

uv does not support the complete set of pip's command-line options and subcommands, although it does support a large subset.uv は pip のコマンドラインオプションとサブコマンドの完全なセットをサポートしていませんが、大部分のサブセットはサポートしています。

Missing options and subcommands are prioritized based on user demand and the complexity of the implementation, and tend to be tracked in individual issues. For example:欠落しているオプションとサブコマンドは、ユーザーの需要と実装の複雑さに基づいて優先順位が付けられ、個別の問題として追跡される傾向があります。例えば：

If you encounter a missing option or subcommand, please search the issue tracker to see if it has already been reported, and if not, consider opening a new issue. Feel free to upvote any existing issues to convey your interest.もし欠落しているオプションやサブコマンドに遭遇した場合は、すでに報告されているかどうかを確認するために問題トラッカーを検索し、報告されていない場合は新しい問題を開くことを検討してください。既存の問題に対しては、あなたの関心を伝えるために自由にアップボートしてください。

Registry authenticationレジストリアクセス認証

uv does not support pip's auto or import options for --keyring-provider. At present, only the subprocess option is supported.uv は pip の auto または import オプションを --keyring-provider に対してサポートしていません。現在、subprocess オプションのみがサポートされています。

Unlike pip, uv does not enable keyring authentication by default.pip とは異なり、uv はデフォルトでキーレリング認証を有効にしていません。

Unlike pip, uv does not wait until a request returns an HTTP 401 before searching for authentication. uv attaches authentication to all requests for hosts with credentials available.他の pip と異なり、uv はリクエストが HTTP 401 を返すまで認証を探しません。uv は、認証情報が利用可能なホストへのすべてのリクエストに認証を添付します。

`egg` support`egg` サポート

uv does not support features that are considered legacy or deprecated in pip. For example, uv does not support .egg-style distributions.uv は、pip でレガシーまたは非推奨と見なされる機能をサポートしていません。たとえば、uv は .egg-スタイルの配布をサポートしていません。

However, uv does have partial support for (1) .egg-info-style distributions (which are occasionally found in Docker images and Conda environments) and (2) legacy editable .egg-link-style distributions.ただし、uv は (1) .egg-info-スタイルの配布（Docker イメージや Conda 環境で時折見られる）と (2) レガシーの編集可能な .egg-link-スタイルの配布に部分的にサポートを提供しています。

Specifically, uv does not support installing new .egg-info- or .egg-link-style distributions, but will respect any such existing distributions during resolution, list them with uv pip list and uv pip freeze, and uninstall them with uv pip uninstall.具体的には、uv は新しい .egg-info-または .egg-link-スタイルの配布をインストールすることをサポートしていませんが、解決中に既存の配布を尊重し、uv pip list および uv pip freeze でリストし、uv pip uninstall でアンインストールします。

Build constraintsビルド制約

When constraints are provided via --constraint (or UV_CONSTRAINT), uv will not apply the constraints when resolving build dependencies (i.e., to build a source distribution). Instead, build constraints should be provided via the dedicated --build-constraint (or UV_BUILD_CONSTRAINT) setting.--constraint（または UV_CONSTRAINT）を介して制約が提供されると、uv はビルド依存関係を解決する際に制約を 適用しません（つまり、ソース配布をビルドするために）。代わりに、ビルド制約は専用の --build-constraint（または UV_BUILD_CONSTRAINT）設定を介して提供する必要があります。

pip, meanwhile, applies constraints to build dependencies when specified via PIP_CONSTRAINT, but not when provided via --constraint on the command line.一方、pip は PIP_CONSTRAINT を介して指定された場合、ビルド依存関係に制約を適用しますが、コマンドラインで --constraint を介して提供された場合には適用しません。

For example, to ensure that setuptools 60.0.0 is used to build any packages with a build dependency on setuptools, use --build-constraint, rather than --constraint.たとえば、setuptools 60.0.0 を使用して setuptools にビルド依存関係のあるパッケージをビルドすることを保証するには、--constraint ではなく --build-constraint を使用します。

`pip compile` defaults`pip compile` のデフォルト

There are a few small but notable differences in the default behaviors of pip compile and pip-tools.デフォルトの動作において、pip compileとpip-toolsにはいくつかの小さなが注目すべき違いがあります。

By default, uv does not write the compiled requirements to an output file. Instead, uv requires that the user specify an output file explicitly with the -o or --output-file option.デフォルトでは、uvはコンパイルされた要件を出力ファイルに書き込みません。代わりに、uvはユーザーに-oまたは--output-fileオプションを使用して出力ファイルを明示的に指定することを要求します。

By default, uv strips extras when outputting the compiled requirements. In other words, uv defaults to --strip-extras, while pip-compile defaults to --no-strip-extras. pip-compile is scheduled to change this default in the next major release (v8.0.0), at which point both tools will default to --strip-extras. To retain extras with uv, pass the --no-strip-extras flag to uv pip compile.デフォルトでは、uvはコンパイルされた要件を出力する際にextrasを削除します。言い換えれば、uvはデフォルトで--strip-extrasを使用し、pip-compileはデフォルトで--no-strip-extrasを使用します。pip-compileは次のメジャーリリース(v8.0.0)でこのデフォルトを変更する予定で、その時点で両方のツールは--strip-extrasをデフォルトとします。uvでextrasを保持するには、uv pip compileに--no-strip-extrasフラグを渡してください。

By default, uv does not write any index URLs to the output file, while pip-compile outputs any --index-url or --extra-index-url that does not match the default (PyPI). To include index URLs in the output file, pass the --emit-index-url flag to uv pip compile. Unlike pip-compile, uv will include all index URLs when --emit-index-url is passed, including the default index URL.デフォルトでは、uvは出力ファイルにインデックスURLを書き込みませんが、pip-compileはデフォルト(PYPI)と一致しない--index-urlまたは--extra-index-urlを出力します。出力ファイルにインデックスURLを含めるには、uv pip compileに--emit-index-urlフラグを渡してください。pip-compileとは異なり、uvは--emit-index-urlが渡された場合、デフォルトのインデックスURLを含むすべてのインデックスURLを含めます。

`requires-python` upper bounds`requires-python` 上限

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の上限）。

`requires-python` specifiers`requires-python` 指定子

When evaluating Python versions against requires-python specifiers, uv truncates the candidate version to the major, minor, and patch components, ignoring (e.g.) pre-release and post-release identifiers.requires-python 指定子に対してPythonのバージョンを評価する際、uvは候補バージョンをメジャー、マイナー、パッチコンポーネントに切り捨て、(例) プレリリースやポストリリースの識別子を無視します。

For example, a project that declares requires-python: >=3.13 will accept Python 3.13.0b1. While 3.13.0b1 is not strictly greater than 3.13, it is greater than 3.13 when the pre-release identifier is omitted.例えば、requires-python: >=3.13を宣言するプロジェクトはPython 3.13.0b1を受け入れます。3.13.0b1は厳密には3.13より大きくありませんが、プレリリース識別子を省略すると3.13より大きいと見なされます。

While this is not strictly compliant with PEP 440, it is consistent with pip.これは厳密にはPEP 440に準拠していませんが、一貫性があります。pipと。

Package priorityパッケージの優先順位

There are usually many possible solutions given a set of requirements, and a resolver must choose between them. uv's resolver and pip's resolver have a different set of package priorities. While both resolvers use the user-provided order as one of their priorities, pip has additional priorities that uv does not have. Hence, uv is more likely to be affected by a change in user order than pip is.通常、要求のセットに対して多くの可能な解決策があり、リゾルバはそれらの間で選択しなければなりません。uvのリゾルバとpipのリゾルバは異なるパッケージの優先順位を持っています。両方のリゾルバはユーザーが提供した順序を優先順位の1つとして使用しますが、pipにはuvにはない追加の優先順位があります。したがって、uvはpipよりもユーザーの順序の変更に影響を受けやすいです。

For example, uv pip install foo bar prioritizes newer versions of foo over bar and could result in a different resolution than uv pip install bar foo. Similarly, this behavior applies to the ordering of requirements in input files for uv pip compile.例えば、uv pip install foo barはbarよりも新しいバージョンのfooを優先し、uv pip install bar fooとは異なる解決策になる可能性があります。同様に、この動作はuv pip compileの入力ファイル内の要求の順序にも適用されます。

Wheel filename and metadata validationホイールファイル名とメタデータの検証

By default, uv will reject wheels whose filenames are inconsistent with the wheel metadata inside the file. For example, a wheel named foo-1.0.0-py3-none-any.whl that contains metadata indicating the version is 1.0.1 will be rejected by uv, but accepted by pip.デフォルトでは、uvはファイル内のホイールメタデータと一致しないファイル名のホイールを拒否します。例えば、foo-1.0.0-py3-none-any.whlという名前のホイールが1.0.1というバージョンを示すメタデータを含んでいる場合、uvはそれを拒否しますが、pipは受け入れます。

To force uv to accept such wheels, set UV_SKIP_WHEEL_FILENAME_CHECK=1 in the environment.そのようなホイールをuvに受け入れさせるには、環境変数にUV_SKIP_WHEEL_FILENAME_CHECK=1を設定します。

Package name normalizationパッケージ名の正規化

By default, uv normalizes package names to match their PEP 503-compliant forms and uses those normalized names in all output contexts. This differs from pip, which tends to preserve the verbatim package name as published on the registry.デフォルトでは、uvはパッケージ名を正規化して、PEP 503準拠の形式に一致させ、すべての出力コンテキストでその正規化された名前を使用します。これは、pipがレジストリに公開されたそのままのパッケージ名を保持する傾向があるのとは異なります。

For example, uv pip list displays normalized packages names (e.g., docstring-parser), while pip list displays non-normalized package names (e.g., docstring_parser):例えば、uv pip listは正規化されたパッケージ名（例：docstring-parser）を表示しますが、pip listは非正規化されたパッケージ名（例：docstring_parser）を表示します：

(venv) $ diff --side-by-side  <(pip list) <(uv pip list)
Package          Version                    Package          Version
---------------- -------                    ---------------- -------
docstring_parser 0.16                         | docstring-parser 0.16
jaraco.classes   3.4.0                        | jaraco-classes   3.4.0
more-itertools   10.7.0                         more-itertools   10.7.0
pip              25.1                           pip              25.1
PyMuPDFb         1.24.10                      | pymupdfb         1.24.10
PyPDF2           3.0.1                        | pypdf2           3.0.1