uv を利用した環境構築が GitHub Codespaces 上で失敗する

[tarepan]

不具合の内容

uv を利用した環境構築が GitHub Codespaces 上で失敗する。
依存パッケージのインストール工程 (uv sync --all-groups) で pyworld のビルドが失敗しインストール工程が failed となる。

現象・ログ

実行ログ

@tarepan ➜ /workspaces/voicevox_engine (master) $ uv sync --all-groups
warning: Ignoring existing virtual environment linked to non-existent Python interpreter: .venv/bin/python3 -> python
Using CPython 3.11.9
Removed virtual environment at: .venv
Creating virtual environment at: .venv
Resolved 85 packages in 1ms
   Updating https://github.com/VOICEVOX/pyopenjtalk (74703b034dd90a1f199f49bb70bf3b66b1728a86)
      Built docopt==0.6.2
   Building pyworld==0.3.5
⠼ Preparing packages... (78/80)                                                                                                                                                                              × Failed to build `pyworld==0.3.5`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta.build_wheel` failed (exit status: 1)

      [stdout]
      running bdist_wheel
      running build
      running build_py
      creating build/lib.linux-x86_64-cpython-311/pyworld
      copying pyworld/__init__.py -> build/lib.linux-x86_64-cpython-311/pyworld
      running build_ext
      Compiling pyworld/pyworld.pyx because it changed.
      [1/1] Cythonizing pyworld/pyworld.pyx
      building 'pyworld.pyworld' extension
      creating build/temp.linux-x86_64-cpython-311/lib/World/src
      creating build/temp.linux-x86_64-cpython-311/pyworld
      clang++ -pthread -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -fPIC -Ilib/World/src
      -I/home/vscode/.cache/uv/builds-v0/.tmpF1oPFN/lib/python3.11/site-packages/numpy/_core/include -I/home/vscode/.cache/uv/builds-v0/.tmpF1oPFN/include
      -I/home/vscode/.local/share/uv/python/cpython-3.11.9-linux-x86_64-gnu/include/python3.11 -c lib/World/src/cheaptrick.cpp -o build/temp.linux-x86_64-cpython-311/lib/World/src/cheaptrick.o

      [stderr]
      /home/vscode/.cache/uv/builds-v0/.tmpF1oPFN/lib/python3.11/site-packages/Cython/Compiler/Main.py:381: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3). This
      has changed from earlier releases! File: /home/vscode/.cache/uv/sdists-v9/pypi/pyworld/0.3.5/zIFCPUnNYHHduZClzCVpx/src/pyworld/pyworld.pyx
        tree = Parsing.p_module(s, pxd, full_module_name)
      error: command 'clang++' failed: No such file or directory

      hint: This usually indicates a problem with the package or the build environment.
  help: `pyworld` (v0.3.5) was included because `voicevox-engine` (v0.24.0) depends on `pyworld`

再現手順

1. GitHub Codespaces の mcr.microsoft.com/devcontainers/python:1-3.11-bookworm image を用いた Python 環境に uv を導入
2. uv sync --all-groups を実行

期待動作

依存パッケージが正常に導入される。

VOICEVOXのバージョン

0.24.0-dev

OSの種類/ディストリ/バージョン

• Linux

$  cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

その他

#1616 のレビューの途中段階では正常動作を確認済みでした。その後の追加 commit で壊れたとかでしょうか？
c.c. @nanae772

[Hiroshiba]

error: command 'clang++' failed: No such file or directory

なんかこれが原因な気がしますね！
GitHub Codespacesでのデフォルトの環境でcmakeが入らなくなった、とかもあり得るかも？
https://github.com/VOICEVOX/voicevox_engine/blob/efdad3629abe11dd8140d7e691ab1fa07a3334ed/CONTRIBUTING.md#%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89

以前できてたはずのバージョンでpip installとかuv syncが成功するなら、そこからのコミットで何かわかるかもですね！

[tarepan]

関連していそうな commits の一覧:

• d41d974 : 依存パッケージのバージョン上限を変更
• chore: pyopenjtalk を最新版に更新（API変更対応） #1640 : pyopenjtalk を bump

エラーの詳細分析

error: command 'clang++' failed: No such file or directory
が最終的なエラー。
となるとビルドツール不足で環境側の問題の可能性がある。
だが uv が仮想環境を作っているため、直感的にはこの仮想環境内に clang++ が足りていないことになりそう。仮想環境への各種インストールは VOICEVOX ENGINE レポジトリ側の責務であるため、バグ混入の可能性がある。

[tarepan]

@Hiroshiba
情報ありがとうございます。
追加コミットの一覧をチェックし怪しそうなものとして上記の commit / PR をリストアップしました。

GitHub Codespacesでのデフォルトの環境でcmakeが入らなくなった

可能性としてはあると思います。
ただ devcontainer.json と image 属性で環境を固定しているので、「どうだろう？」という第一感です。ただ patch version まで固定できているかわからないので、環境依存の問題かどうかちょっと深ぼってみます。

[tarepan]

uv 無しでの導入チェック

uv に由来するものか否かを検証するため、pip を用いて直接 GitHub Codespaces 上に依存パッケージを導入しました。

実行ログ

@tarepan ➜ /workspaces/voicevox_engine (master) $ python -m pip install -r requirements.txt -r requirements-dev.txt -r requirements-build.txt
(略)
Downloading pyinstaller_hooks_contrib-2025.2-py3-none-any.whl (351 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 351.0/351.0 kB 29.6 MB/s eta 0:00:00
Building wheels for collected packages: pyworld, docopt, pyopenjtalk
  Building wheel for pyworld (pyproject.toml) ... done
  Created wheel for pyworld: filename=pyworld-0.3.5-cp311-cp311-linux_x86_64.whl size=1052601 sha256=f5e0922ea76f8e1c79a436335f530b2c351034fd2c36fa9fa50297414d44d658
  Stored in directory: /home/vscode/.cache/pip/wheels/26/f0/db/ebcd5cdfe5ad7d229917d3a8db6f18f0cf40f099bf878e294d
  Building wheel for docopt (setup.py) ... done
  Created wheel for docopt: filename=docopt-0.6.2-py2.py3-none-any.whl size=13706 sha256=48e63f0ae4f578c51ea58a296c45489e3fb96694eecdf0770ce06242ecc819a9
  Stored in directory: /home/vscode/.cache/pip/wheels/1a/b0/8c/4b75c4116c31f83c8f9f047231251e13cc74481cca4a78a9ce
  Building wheel for pyopenjtalk (pyproject.toml) ... done
  Created wheel for pyopenjtalk: filename=pyopenjtalk-0.1.dev251+g74703b0-cp311-cp311-linux_x86_64.whl size=6454821 sha256=14616563d5633c7606832fa1cfa814ef3fe66d72e1040f24c0d201fd0aea7583
  Stored in directory: /home/vscode/.cache/pip/wheels/3d/51/31/ccf14d704254c39683372e04ffaa5baec347b85928948d383d
Successfully built pyworld docopt pyopenjtalk
(略)
Successfully installed altgraph-0.17.4 annotated-types-0.7.0 (略)

結果、インストールが正常に完了しました。

この結果から以下の原因により環境構築が失敗している可能性があると考えます:

• A: uv に不具合がある
• B: uv がつくる仮想環境へ導入すべきツールの指定が不足している
• C: uv の導入によりインストールされる依存パッケージが変わり、それがエラーを起こしている

ログをみた感じ、C が怪しいと考えています。
pip 利用時（≒ uv 導入前）には pyworld を clang++ でリビルドしているっぽい挙動は見た覚えがないです。しかし uv 利用時のログには Compiling pyworld/pyworld.pyx because it changed. との文言があり、リビルドをしていそうです。
uv が自動で用意してくれている Python 環境が従前のものと（意図せず）変わっているという可能性はありそうでしょうか？

[sabonerune]

uv導入PR時にpyopenjtalkのビルドで似たような現象が発生しています。
#1616 (comment)

ここではpyopenjtalkがclangで既に削除されていたキーワードregisterを使っていたことが原因なのでpyopenjtalkを更新することで解決しましたがそもそもclangが使われている理由に関してはよく分かっていません。
(一応uvがインストールするpythonのビルドにclangが使われていることで優先的に使われている可能性が高そうですが…)

また、自分のWSL Ubuntu22.04ではclangをインストールしていませんが問題なく依存関係のインストールに成功しています。

[Hiroshiba]

ちょっと把握しきれていませんが、 @sabonerune さんの仰るとおり、uvに変えたことによってclangが優先的に使われるようになった説があり得るかもと思いました！

今までもビルドは行われていたと思われますが（pyworldにはWindows版以外のホイールがないっぽいため）、clangではなくgccあたりが使われていた･･･のかもです。
clangが必要なんですか？ってuvのissueは解決されていることになっていますが･･･どう回避すれば良いんだろう･･･。

https://docs.astral.sh/uv/reference/troubleshooting/build-failures/#command-is-not-found
を見るとuvにはclangが良くてbuild-essential入れれば入るよ的な案内がありました。
このあたりよくわかってないのですが、cmake環境をつくれば勝手にclangは入るんですかね･･･。（入らないならREADME変えないといけないなぁと思い）

[tarepan]

お二方情報ありがとうございます。

bash で gcc コマンドと clang コマンドを実行したところ、gcc は動いて、clang はコマンド見つからずで失敗しました。
これは clang が必要なことを示唆していると考え、LLVM を公式の手順に従って導入し追加パッケージ等を揃えたところ、エラーが解消し正常に依存パッケージがインストールできました。pytest 等の静的解析も実行できました。

ただ、これらのインストールはそれなりに時間が掛かるため、開発環境をしょっちゅう捨てて作り直す devcontainer/Docker 環境を使うコントリビューターにとって、（LLVM/clang 導入を前提とした）uv 必須化は DX の低下を招いている可能性があります。
例えば GitHub Codespaces を使っている私の場合、パッケージ更新が入っている PR の作成・レビュー時には都度環境を捨ててパッケージインストールからチェックしています。LLVM/clang 導入を要するとこの 1 イテレーションが10倍くらいの長さになるため、実務的にとても厳しいです。

LLVM/clang 導入が不要なら uv のメリットのみを享受できるため、何らかの回避ルートがあれば良さそうです（gcc を使えるようにする、ビルドをなんかうまいことやる、とか？）。
私は C/C++・Cython・uv どれもさっぱりでして、もし知識のある方がいらっしゃればお力を借りたいです🙇

[sabonerune]

uvのissueを色々調べていたらCC CXX環境変数でコンパイラを変更できるようです。

それと自分の環境でclangをインストールせずにビルドが成功した理由はuv 0.6.14を使っているからで0.7.0で用意した環境を使ってpyworldをインストールしたところclang++が見つからないというエラーが発生しました。
どうやらuv 0.6.14と0.7.0でインストールしたときではsysconfigの内容が異なるようです。

これはPythonをインストールするときインストール情報を書き換えているuvのバグ?

[tarepan]

ビルドが成功した理由はuv 0.6.14を使っているから

これは盲点でした、貴重な情報ありがとうございます。

CONTRIBUTING.md に uv のバージョン指定が無い（docs）ことのデメリットだと感じます。poetry のときは厳密にバージョン管理していました。サポートバージョンを決めないと切り分け困難な issue が増えそうです（例: この issue）。
「バージョン固定の是非」「VOICEVOX ENGINE が公式サポート（=動作検証）する uv のバージョン」を個別 issue で議論した方が良さそうに感じます。uv 導入を進めてくださった @Hiroshiba @nanae772 さんが最も知見がありそうなので、もしお時間あれば検討して頂けると嬉しいです。

[Hiroshiba]

uvは今のところプロジェクトで管理しないもので、大体どこでもどのバージョンでも動く前提で組んでるので、バージョン固定はできないんですよね…。
今の方針のまま案内するとすれば、ドキュメントに「uv7使っててclangなかったらこの環境変数つけて」みたいな感じになるかなと…

ちょっと今回はuvの弱点がひとつ見つかったということで、uvが直るかどうかしばらく様子見する方針が良いかと思っています。
これでuv側がしばらく直らないなら、どうにかしてuvのバージョン固定が必要だと思います。
すぐ直ったら、まあたまにgithubが落ちてるみたいな感じと同じで、一旦もうしばらく様子見するとかでどうでしょうか…。

[tarepan]

uvが直るかどうかしばらく様子見する方針が良い

👍️
uv の信頼性や更新頻度に関する知見が私に無いため、@Hiroshiba さんの判断がより信頼できると考えます。

様子見するとして、このバグ（？）で影響を受けるコントリビューターの範囲（特定のマイナー環境 only か、ほぼ全員か）を知っておくことは有用と考えます。
@Hiroshiba さんの環境で利用されている uv のバージョンはいくつでしょうか？またそちらの環境で uv 7 へアップデートしても問題無く機能する感じでしょうか？