uv 0.13.0がUTCで10月9日、韓国時間で10月10日に公開された。バージョンを要求も固定もしていないときにダウンロードする既定の安定版Pythonが、3.14から3.15に変わった。

すでにインストールされている互換Pythonは引き続き使われる。たとえばuv venvは、インストール済みのPython 3.14をそのまま使える。

適切なインタープリターがなく自動ダウンロードが有効な場合、uv venvやuvx pythonなどのコマンドがPython 3.15をダウンロードすることがある。リリースノートは、uv venv --python 3.14のように3.14を明示的に要求するか、プロジェクトでuv python pin 3.14によりバージョンを記録すればこの動作を避けられると説明している。

Pythonのバージョン要求と自動ダウンロード

uvのPythonバージョンのドキュメントによると、--pythonオプションは必要なバージョンを要求し、uv python pinは現在のディレクトリに.python-versionファイルを作る。uvは作業ディレクトリとその親ディレクトリでこのファイルを探し、既定のバージョン要求として使う。

自動ダウンロードは、python-downloadsの設定で無効にするか、どのuvコマンドにも--no-python-downloadsフラグを渡して無効にできる。

uvの実行ファイルのバージョンを固定することと、Pythonのバージョンを固定することは別の判断だ。ツールのバージョンはどの選択動作を使うかを、Pythonの要求はどのインタープリターで作業するかを決める。

厳しくなった制約ファイルの扱い

以前は、requirementsファイルから-cで取り込んだ制約ファイルの--require-hashesは無視されていた。現在はこの指示に従い、インストールするすべての要件にハッシュを求めるため、ハッシュのない項目があると以前は成功していたインストールが失敗することがある。

指示がある限り、この動作は無効にできない。足りないハッシュを補うか、ハッシュ検査を意図していないなら取り込んだ制約ファイルから指示を消す。

取り込んだ制約ファイルのeditable（-e）要件も、黙って無視される代わりにエラーで拒否されるようになり、pipの動作に合わせた形だ。該当項目は-rで渡すrequirementsファイルへ移すか、--editableで直接渡す。

新しいCIで表れるインタープリターの違い

開発用のコンピューターはインストール済みの3.14を再利用して成功し、まっさらなCI環境は3.15をダウンロードすることがある。同じuvのバージョンでも、インストールされているPythonによって結果が分かれるわけだ。

テストの記録に実際に選ばれたインタープリターのバージョンを残せば、2つの環境の違いをすぐ比べられる。

新しい失敗が示すもの

ハッシュのエラーはresolverの退行ではなく、以前は無視されていた完全性のポリシーが初めて適用された結果かもしれない。調べるべきなのはトップレベルのrequirementsファイルだけでなく、-cでつながったすべてのファイルだ。

editable項目を移すときは、制約とインストール要求の役割が異なるため、移した後に実際にインストールされるものが変わることがある。

注意点：2つの変化が同時に重なるとき

インタープリターの選択と制約ファイルの扱いが同じアップグレードで一緒に変わると、失敗の原因が2通りになり、成功しても環境の違いが隠れることがある。この記事はuvのインストール、環境の作成、依存関係の解決を自ら実行していない。

10月10日号は韓国の日付に従ったもので、リリース元の日付は10月9日だ。

uv 0.13.0は固定していないPythonのダウンロードを3.15に移し、取り込んだ制約ファイルのハッシュとeditableの規則を強制するため、アップグレードの失敗はインタープリターの選択と制約ファイルの扱いに分けて見て初めて原因が分かる。