fix(windows): make first-run setup work on Windows

[joecer21]

Fixes #1.

Three independent Windows-only failures that together prevent first-run setup from completing. Each has its own root cause and its own fix; they're described separately below. Another participant on #1 has confirmed these resolve the install failure on their Windows machine.

Scope note: severity differs a lot between them. Fix 1 affects every Windows user, including the packaged installer. Fixes 2 and 3 are narrower and environment-dependent — I've said where each actually fires rather than implying all three are universal.

1. pip.exe cannot upgrade itself (blocking)

bootstrap() ran every pip command through venv\Scripts\pip.exe, and the first of those upgrades pip itself. pip refuses that when launched as pip.exe, because it can't replace its own running executable:

ERROR: To modify pip, please run the following command:
C:\...\venv\Scripts\python.exe -m pip install -q -U pip wheel setuptools

Since it's the first pip call in bootstrap(), setup could never get past it on Windows. The UI showed only pip upgrade failed (1).

All four call sites now go through python -m pip, which is the recommended invocation on every platform and is a no-op behavioural change on macOS. That includes updateYtDlp(), which hit the same refusal — so the in-app "update yt-dlp" repair action was also broken on Windows, meaning the documented recovery path for yt-dlp breakage didn't work there either.

venvPip() becomes unused and is removed, since noUnusedLocals is enabled in tsconfig.node.json.

2. Bare tar can resolve to GNU tar

extractArchive() spawned tar by bare name, letting PATH pick the binary. Windows may have two, and Git for Windows ships GNU tar. GNU tar comes from the Unix world where host:path means a remote tape drive, so given C:\Users\... it treats C: as a hostname:

tar (child): Cannot connect to C: resolve failed
tar: Error is not recoverable: exiting now     (exit 2)

Extraction then produced nothing, and setup reported No suitable python3 found on this machine — pointing at Python detection rather than the extract that actually failed. Now prefers Windows' built-in bsdtar by absolute path, falling back to tar elsewhere. macOS behaviour is unchanged.

This only fires when GNU tar precedes System32 on PATH (e.g. launching from Git Bash), so it won't affect every Windows user — but it's a coin flip depending on environment.

3. run.cjs passed an unquoted path to a shell

runSteps() enables shell: true for .cmd binaries but passed the resolved path unquoted, so a checkout path containing spaces was split at the first space:

'D:\Audio' is not recognized as an internal or external command

Now quoted when shelling out. Source builds only; packaged users are unaffected.

Testing

• Full first-run setup completed on Windows 11 (x64), Node 24.19.0, bootstrapped python-build-standalone 3.11.10
• Separated a track end-to-end: download, separation, playback, and per-stem WAV export all worked
• npm run typecheck:node passes clean
• Independently confirmed by another participant on First-run setup fails on Windows (three separate issues) #1

Deliberately not included

• CUDA support. As noted in First-run setup fails on Windows (three separate issues) #1, separate.py selects mps or cpu only, so Windows always runs on CPU. That's a feature change rather than a bug fix and belongs in its own PR — happy to raise it separately if it's of interest.
• Surfacing stderr on the failing steps. Both bugs above were harder to diagnose than necessary because those spawn calls attach only a close handler, so pip's actionable message was discarded. Worth doing, but it's a behavioural change beyond these fixes, so I've left it out.
• Python detection. pyCandidates() probes hardcoded Python312/311/310/39 paths, so newer system Pythons are invisible. In my case that was accidentally the right outcome (demucs/torch have no 3.14 wheels), but it works by luck. Also left alone here.

[danvelope]

wow thank you so so much 🙇‍♂️