Skip to content

fix(hyperframes-media): install MusicGen deps via python3 -m pip, not bare pip#1894

Draft
miguel-heygen wants to merge 1 commit into
mainfrom
fix/bgm-pip-install-python3-module
Draft

fix(hyperframes-media): install MusicGen deps via python3 -m pip, not bare pip#1894
miguel-heygen wants to merge 1 commit into
mainfrom
fix/bgm-pip-install-python3-module

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

Summary

"audio.mjs's local MusicGen fallback calls spawnSync('pip', ...) not 'pip3' - silently no-ops on machines where only pip3 is on PATH (Homebrew Python), so the documented 'auto-installed on demand' MusicGen path never actually installs; worked around with a manual venv."

pipInstall() in bgm.mjs spawned a bare pip binary. Many Homebrew/system Python installs expose only python3/pip3 on PATH, so the spawn silently ENOENTs and the "auto-installed on demand" local MusicGen path never actually installs anything — indistinguishable from any other install failure, since spawnSync's status just comes back non-zero either way.

Fix

Switched to python3 -m pip install, matching this same file's own pyOk() helper, which already always invokes python3 explicitly (never a bare python). This also closes a second, more subtle latent bug: even with a working pip/pip3 on PATH, it could resolve to a different Python installation than the python3 binary pyOk() probes against if more than one is installed — -m pip guarantees the install lands in the exact interpreter being checked.

Test plan

  • Manually verified python3 -m pip --version succeeds in this environment
  • No automated test added — this is a literal command-array swap with no new branching logic, and spawnSync is a named import from node:child_process with no clean mocking path available here without a refactor disproportionate to the fix's size (this Node version doesn't support node:test's mock.module() without an experimental flag, confirmed by trying it)

… bare pip

pipInstall() spawned a bare "pip" binary. Many Homebrew/system Python
installs expose only python3/pip3 on PATH, so the spawn silently ENOENTs
and the documented "auto-installed on demand" local MusicGen path never
actually installs anything - the failure is invisible since spawnSync's
status just comes back non-zero like any other install failure.

Switched to `python3 -m pip install`, matching this same file's own
pyOk() convention of always invoking python3 explicitly. This also
closes a second latent bug: a bare pip/pip3 could resolve to a different
Python installation than the python3 binary pyOk() probes against if
more than one is on PATH, so `-m pip` guarantees the install lands in the
exact interpreter being checked.

Manually verified `python3 -m pip --version` succeeds in this
environment. No automated test added - this is a literal command-array
swap with no new branching logic, and spawnSync is a named import from
node:child_process with no clean mocking path available without a
larger refactor disproportionate to the fix's size.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant