Four pins and one probe, each found by building it rather than reading about it.

mmpose's RTMO head imports mmdet unconditionally although mmpose lists it as
optional, so `import mmpose.apis` dies without it; mmdet then asserts
mmcv < 2.2.0 at import; openmmlab publishes a cp311 mmcv 2.1.0 wheel on exactly
one index, cu121/torch2.1. So the torch pin is 2.1.2 and it is dictated by mmcv,
not by MuseTalk. mmengine imports pkg_resources to find mmpose's config
directory, which setuptools dropped in 81, making setuptools<81 a runtime pin.

chumpy, which mmpose depends on, has a setup.py that does `import pip` and
cannot build in an isolated environment. Named per package rather than turning
isolation off wholesale, which would let everything else build against a
half-installed venv.

The venv probe was wrong, not the install: it ran a bare interpreter, so
face_detection -- vendored under musetalk/utils, not a package -- came back
missing and a complete install was reported broken. It runs against the install
root with the engine's own PYTHONPATH now, as a real run does, and asks for
mmpose.apis rather than mmpose, since the package imports fine and the submodule
is what fails.

Also: uv's HTTP timeout is too short for hundred-megabyte wheels off third-party
indexes, and the abort reads as a corrupt wheel rather than a timeout. And a
per-run directory is swept after a day -- a failed run keeps its task file and
frames, which is what you read to find out why, but not for ever.

Verified live: MuseTalk v15 lip-synced a 2s 480x480 clip in 92s, 48 frames with
the audio muxed, and the successful run removed its own directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZnLhydX9QqUcfBbqLu