fix: loosen torch and torchaudio version constraints for Python 3.13+ compatibility

[cpiprint]

Description

The local audio engine installer currently crashes on newer Mac and Windows environments running modern Python runtimes (like Python 3.13) because torch and torchaudio are strictly locked to ==2.5.1. Python 3.13 cannot resolve those older pre-compiled versions, throwing a No matching distribution found build error.

Changes Made

• Updated torch==2.5.1 to torch>=2.5.1 in src/main/env.ts
• Updated torchaudio==2.5.1 to torchaudio>=2.5.1 in src/main/env.ts

This adjustment allows the app's internal child process builder to pull down the nearest compatible wheel file for whatever modern Python environment is present on the host device.

[danielravina]

Thanks @cpiprint for the PR! Is this meant to fix #3? If so, I'd suggest a one-line change instead of loosening the torch pin.

The real cause: detectTools() accepts any Python minor >= 9 with no upper bound (src/main/env.ts:261), so on macOS it picks up the system Python 3.14, and torchaudio==2.5.1 has no wheels beyond 3.12 — hence the pip failure. Windows is unaffected since it only probes 3.9–3.12 paths and falls back to the bundled runtime.

if (major > 3 || (major === 3 && minor >= 9 && minor <= 12)) {

This makes 3.13/3.14 fall through to the bundled CPython 3.11 (confirmed working on macOS in the issue thread). Want to give that a try?

[danielravina]

Also, do you mind dropping the package.json/package-lock.json changes? They seem unrelated to the fix but I'm happy to take that as a separate PR if you'd like.

[cpiprint]

Thanks for the feedback, @danielravina! That makes total sense. I reverted the torch pin adjustment and applied the upper-bound limit constraint (minor <= 12) to detectTools(). I also dropped the unrelated package changes as requested. The PR should be cleanly updated now!

[danielravina]

Thanks @cpiprint! the cap looks exactly right, nice work!

One small thing: the revert of the package.json / package-lock.json changes doesn't seem to have made it into the push. the Files Changed tab still shows both files as modified. Might just be a commit that didn't get pushed? If you can drop those hunks (revert commit or force-push, either is fine), this is good to merge

[joecer21]

Looks right to me and solves the blocker on 1st time installs only.

However, for users that tried and failed before:

bootstrap() creates the venv without --clear, so a failed setup leaves a half-built venv that later runs reuse rather than rebuild. Anyone who already hit this stays broken even after. Their venv is still bound to 3.14, so the interpreter fix never reaches them.

Everyone on #3 had to rm -rf the venv by hand before the workaround took.

-      const child = spawn(state.python.path as string, ['-m', 'venv', venv])
+      const child = spawn(state.python.path as string, ['-m', 'venv', '--clear', venv])

bootstrap() only runs when setup is incomplete (a ready venv skips the setup screen entirely), so it can't wipe a working install, and pip's wheel cache keeps the rebuild cheap rather than re-downloading the ~2GB.

All yours if you want it, or I can send it as a separate PR after this merges.

[danielravina]

Thanks @cpiprint and @joecer21! To keep things moving I'm merging this and will clean up the remaining things myself.

[cpiprint]

Thanks, my friend. I was out on the road.