ci: keep pins.json in sync with pyproject.toml

.github/workflows/python-tests.yml

@@ -83,6 +83,9 @@ jobs:
               - 'invokeai/**'
               - '!invokeai/frontend/web/**'
               - 'tests/**'
+              # tests/ covers a few of these (e.g. test_check_pins.py, test_docs_json_export.py)
+              - 'scripts/**'
+              - 'pins.json'
 
       - name: setup uv
         if: ${{ steps.changed-files.outputs.python_any_changed == 'true' || inputs.always_run == true }}

.github/workflows/uv-lock-checks.yml

@@ -1,6 +1,8 @@
-# Check the `uv` lockfile for consistency with `pyproject.toml`.
+# Check the `uv` lockfile and `pins.json` for consistency with `pyproject.toml`.
 #
-# If this check fails, you should run `uv lock` to update the lockfile.
+# If the lockfile check fails, you should run `uv lock` to update the lockfile.
+# If the pins check fails, update the torch index URLs in `pins.json` to match
+# the `[[tool.uv.index]]` entries in `pyproject.toml` (see scripts/check_pins.py).
 #
 # Also checks that the lockfile keeps working for linux/aarch64, which no test job covers.
 # This reads the lockfile only - no ARM hardware or extra resolution needed.
@@ -57,6 +59,8 @@ jobs:
             uvlock-pyprojecttoml:
               - 'pyproject.toml'
               - 'uv.lock'
+              - 'pins.json'
+              - 'scripts/check_pins.py'
             aarch64check:
               - 'scripts/check_aarch64_lock.py'
 
@@ -72,6 +76,11 @@ jobs:
         run: uv lock --locked # this will exit with 1 if the lockfile is not consistent with pyproject.toml
         shell: bash
 
+      - name: check pins.json
+        if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || inputs.always_run == true }}
+        run: python3 scripts/check_pins.py # pins.json is consumed by the launcher; keep its torch index URLs in sync with pyproject.toml
+        shell: bash
+
       - name: check aarch64 support in lockfile
         # Also runs when the check itself changes, so edits to it are exercised.
         if: ${{ steps.changed-files.outputs.uvlock-pyprojecttoml_any_changed == 'true' || steps.changed-files.outputs.aarch64check_any_changed == 'true' || inputs.always_run == true }}

docs/src/content/docs/start-here/manual.mdx

@@ -131,6 +131,16 @@ The following commands vary depending on the version of Invoke being installed a
               ```sh
               --torch-backend=rocm7.1
               ```
+
+              :::caution[ROCm and torch 2.12]
+                The `rocm7.1` index currently defaults to torch 2.12.x, which has been reported to
+                break generation on ROCm ([#9410](https://github.com/invoke-ai/InvokeAI/issues/9410)).
+                Until that issue is closed, also constrain torch when installing:
+                ```sh
+                uv pip install <PACKAGE_SPECIFIER>==<VERSION> "torch<2.12" --python 3.12 --python-preference only-managed --torch-backend=rocm7.1 --force-reinstall
+                ```
+                This workaround applies to the reported ROCm case only.
+              :::
             </TabItem>
             <TabItem label="All other cases">
               Do not use a torch backend.

pins.json

@@ -2,6 +2,7 @@
   "python": "3.12",
   "torchIndexUrl": {
     "win32": {
+      "cpu": "https://download.pytorch.org/whl/cpu",
       "cuda": "https://download.pytorch.org/whl/cu128"
     },
     "linux": {

pyproject.toml

@@ -51,6 +51,12 @@ dependencies = [
   # Loosely pinned, will respect requirement of `diffusers[torch]`. Split by platform: linux/win allow
   # >=2.10 so the rocm extra can use torch 2.10.0+rocm7.1, while macOS stays on 2.7.x — newer macOS torch
   # wheels exercise MPS on CI runners (no usable Metal GPU) and fail with MPS OOM.
+  # Deliberately NOT capped below 2.12 here. torch 2.12.x+rocm7.1 is reported to break generation (#9410), but
+  # this range is what every backend-agnostic install resolves against — manual installs use
+  # `--torch-backend=<x>` with no extra (see docs/start-here/manual), so a blanket cap would also
+  # reject torch>=2.12 on Windows/Linux CUDA, CPU and ARM64, where 2.12 has no known problem.
+  # The ROCm path is constrained where it can actually be targeted: the `rocm` extra below pins an
+  # exact version, and the manual docs carry the ROCm-specific caveat.
   "torch>=2.7.0,<3.0; sys_platform != 'darwin'",
   "torch>=2.7.0,<2.8.0; sys_platform == 'darwin'",
   "torchsde",                             # diffusers needs this for SDE solvers, but it is not an explicit dep of diffusers