Repository navigation
build(windows): install CUDA torch explicitly for the NVIDIA package (#316) - #318
Merged
Merged
Conversation
…316) The non-CpuOnly path relied on `pip install .` yielding a CUDA torch, but the Windows PyPI torch wheel is CPU-only (unlike Linux, whose default wheel bundles CUDA). GPU support in the "NVIDIA" package was therefore an implicit property of the build host's pip resolution and could silently regress to CPU. Force-install the cu124 wheel from the PyTorch index so the NVIDIA build is deterministically GPU-capable; the CPU path is likewise made explicit so it downgrades a host that resolved a CUDA wheel.
thcp
added a commit
that referenced
this pull request
Jul 18, 2026
…318) (#320) #318 force-installed the CUDA torch wheel into the NVIDIA package, which pushed the release zip to 2456 MB -- over GitHub's 2 GiB release-asset cap (2147483648 bytes) -- so the Windows NVIDIA asset upload failed on the v0.8.0-alpha.12 release. Bundling was the wrong approach: the desktop app already installs the CUDA build on first run via ensure_torch_device (which picks the cuXXX index matching the detected GPU's compute capability / driver). The NVIDIA package is meant to ship base torch small (~419 MB zip) and pull CUDA on first launch. #317 is the actual fix -- it makes that first-run install trigger again after a CPU->NVIDIA build swap. Restore the non-CpuOnly path to base torch and document why not to bundle, so this isn't reintroduced. Co-authored-by: Thales <>
thcp
added a commit
that referenced
this pull request
Aug 25, 2026
) * Ship the challenge solver without costing anyone a reinstall (#432, #438) Extraction rides a fallback client that skips YouTube's signature/n-challenge. It works today, yt-dlp has deprecated it, and fixing that needs two things: the solver script and a JavaScript engine to run it. The obvious route was a yt-dlp-ejs dependency and a binary in data/. Both would have reached only fresh installs. runtimeId is sha256(uv.lock) and the desktop updater stands down when it changes, because it can replace backend/ but never python/. A new dependency would therefore have sent every existing desktop install to a manual reinstall. The in-app updater is something users have been told works; spending that to ship a fix nobody has asked for is a bad trade. So both halves go where the updater can reach them. The solver is vendored into app/_vendor, which becomes backend/app/_vendor in a package. 53 KB of pure Python that StemDeck never imports and yt-dlp discovers at runtime, so it is a payload rather than a dependency, and it belongs in the app layer. app/__init__ puts it on sys.path before anything else, which is the only place that can work: yt-dlp resolves its optional dependencies at import time and pipeline.download imports yt_dlp at module level. uv.lock is untouched, so runtimeId does not move. The engine goes to backend/jsruntime rather than data/jsruntime for the same reason: the updater replaces backend/ and leaves data/ alone. quickjs-ng, pinned by version and SHA256 like the macOS FFmpeg download (#172), fetched at package time by all three build scripts. 2 MB against deno's 110 MB, against a 2 GiB asset cap this project has already hit (#318, #222). Vendoring usually means remembering to update something. scripts/update_vendored_ejs.py removes that: it exits non-zero when PyPI has a newer release and takes it with --apply, verifying the wheel checksum first. Verified with nothing pip-installed: the solver resolves from app/_vendor, yt-dlp finds it, quickjs runs, and six audio formats resolve where the solverless path found one. Two things unchanged and already on the issues. The web client still fails for want of a PO token yt-dlp cannot mint, so a flagged IP may still need cookies. And the solver costs about 7.8 s per extraction, measured. * Assert the build scripts and the runtime lookup still agree A cross-language contract with nothing checking it. Three shell and PowerShell scripts decide where the JS engine lands; Python decides where to look for it. A mismatch does not fail a build or a test, it shows up as YouTube imports quietly degrading on one platform, because yt-dlp just falls back to the client that skips the challenge. Two tests. One pins the packaged layout: in a package this file is backend/app/core/config.py, so parents[2] is backend/, and a refactor of that index would leave every desktop package without an engine. The other reads the three scripts and asserts they still install into backend/ and still verify a checksum before trusting the binary. * Drop scripts/release_download_chart.py from this branch Swept in by a careless 'git add scripts/'. It is unrelated work in progress that was untracked before this branch started, and it belongs to whoever is writing it, not to a change about YouTube's challenge solver. The file is untouched on disk. --------- Co-authored-by: Thales <>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up hardening for #316.
Problem
The Windows NVIDIA build's GPU support was never guaranteed by the packaging script. The non-
-CpuOnlypath does onlypip install "$Root"and trusts PyPI to serve a CUDA torch wheel — true on Linux (default wheel bundles CUDA) but false on Windows, where the PyPI torch wheel is CPU-only. So the "NVIDIA" package being GPU-capable was an implicit property of the build host's pip resolution (e.g. a cu124 index configured in the runner). If that host config ever changes, releases silently regress to CPU torch — exactly the CPU-only artifact a plain-PyPI build produces locally.Fix
Mirror the existing
-CpuOnlyforce-reinstall in reverse: the NVIDIA path now force-installstorch==2.6.0+cu124 torchaudio==2.6.0+cu124fromhttps://download.pytorch.org/whl/cu124, making the GPU build deterministic regardless of build host. The Windows CUDA wheel is self-contained (bundles the CUDA DLLs; no separatenvidia-*deps like Linux), so--no-depsis correct. The CPU path comment is updated to note it also downgrades a host that resolved a CUDA wheel.Verification
Parser::ParseFile, no syntax errors).-CpuOnlyreinstall pattern.torch.version.cuda != None/__version__ == "2.6.0+cu124"and grow to the expected ~1.6 GB.Scope
Windows portable packaging only. macOS (MPS) and Docker (Linux CUDA baked into the image) are unaffected.