Commit c700a40
committed
deps: raise torch upper bound to <2.13
`pyproject.toml`'s `torch>=2.8,<2.12` cap was older than what the CI
build pipeline now picks up. `env/build_requirements.txt` and
`env/test_requirements.txt` leave `torch` unpinned, so `uv pip install
--extra-index-url https://download.pytorch.org/whl/cu130 ...` resolved
it to whatever was newest on the CUDA index.
That worked while the newest cu130 torch matched the wheel's range.
Once torch `2.12.0+cu130` was published, the build env installed
2.12.0+cu130 (so fvdb's `.so` ended up compiled against the 2.12 ABI,
which includes `at::TensorBase::const_data_ptr<int8_t>`), but the
*test* env's install of the resulting wheel hit pyproject's `<2.12`
ceiling and pip downgraded torch to the CPU-only `2.11.0` from PyPI
(which is missing those CUDA-side template symbols). The CUDA 13.0
unit-test pipeline then surfaces:
ImportError: .../libfvdb.so: undefined symbol:
_ZNK2at10TensorBase14const_data_ptrIaEEPKT_v
at `import fvdb` time. Every CUDA 13.0 PR since 2026-05-16 has been
red on this; CUDA 12.8 isn't affected (its index still serves a
wheel in-range).
Bumping the upper bound to `<2.13` lets the wheel and both the build
and test environments converge on the same torch 2.12.x build, with
no extra pin needed in the requirements files. A short comment in
pyproject.toml documents the convention so the next torch minor
release bump is mechanical.
Signed-off-by: Francis Williams <francis@fwilliams.info>1 parent bedf87e commit c700a40
1 file changed
Lines changed: 7 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
14 | | - | |
15 | | - | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
16 | 21 | | |
17 | 22 | | |
18 | 23 | | |
| |||
0 commit comments