fix: remove --torch-backend from plugin dependency compilation#495
fix: remove --torch-backend from plugin dependency compilation#495ryanontheinside wants to merge 1 commit intomainfrom
Conversation
The compile step (_compile_plugins) resolves compatible package versions, while the install step (_sync_plugins) fetches platform-specific builds. Passing --torch-backend cu128 during compilation conflates these concerns — it forces the resolver to use the cu128 index for all torch ecosystem packages, even those that lack wheels on that index for the current platform (e.g. torchao 0.15.0+cu128 has no Windows wheels). Without this flag, the compile step resolves versions from PyPI where torchao is available as a platform-independent wheel (py3-none-any). The install step still uses --torch-backend cu128 to fetch the correct CUDA builds for torch and torchvision. This works because local version tags (+cu128) only affect which binary is downloaded, not version resolution or dependency metadata. Signed-off-by: RyanOnTheInside <7623207+ryanontheinside@users.noreply.github.com>
But, since torchao is a part of the repo's pyproject.toml wouldn't this step still trigger a lookup of non-existent CUDA Windows builds for torchao? I actually noticed this problem recently and it happens specifically with more recent versions of uv that include the changes in this PR that add torchao to the list of packages that are affected by the
Though I think that bit is missing from the Daydream docs.
If you think you have a solution for this then I think it makes sense to move forward with it. But, it's not clear to me that the current set of changes suffice. If there isn't an immediate solution for this, then I think using |
|
Actually I realized the Docker image does not pin the uv version to 0.9.11 so that could be worth trying first as a stopgap too. I haven't had a chance to test yet though... |
2 participants
The compile step (_compile_plugins) resolves compatible package versions, while the install step (_sync_plugins) fetches platform-specific builds. Passing --torch-backend cu128 during compilation conflates these concerns — it forces the resolver to use the cu128 index for all torch ecosystem packages, even those that lack wheels on that index for the current platform (e.g. torchao 0.15.0+cu128 has no Windows wheels).
Without this flag, the compile step resolves versions from PyPI where torchao is available as a platform-independent wheel (py3-none-any). The install step still uses --torch-backend cu128 to fetch the correct CUDA builds for torch and torchvision. This works because local version tags (+cu128) only affect which binary is downloaded, not version resolution or dependency metadata.