🐛 Bugs / Unexpected behaviors
PyTorch3D has packaging compatibility issues under modern PEP 517 / PEP 660 local build workflows.
The main problems appear to be:
setup.py passes absolute source paths to setuptools for the C++/CUDA extension
- the project does not provide minimal
pyproject.toml metadata for modern build frontends
Instructions To Reproduce the Issue:
- Any changes you made (
git diff) or code you wrote
No source changes are required to reproduce the original failure.
- The exact command(s) you ran:
tmpdir=$(mktemp -d)
uv venv "$tmpdir/venv"
UV_HTTP_TIMEOUT=300 uv pip install --python "$tmpdir/venv/bin/python" \
--index-strategy unsafe-best-match \
setuptools wheel numpy iopath torch==2.10.0+cu128 \
--index-url https://pypi.org/simple \
--extra-index-url https://download.pytorch.org/whl/cu128
UV_HTTP_TIMEOUT=300 CUDA_HOME=/usr/local/cuda-12.8 \
PATH="/usr/local/cuda-12.8/bin:$PATH" \
uv pip install --python "$tmpdir/venv/bin/python" \
/path/to/pytorch3d \
--no-build-isolation
- What you observed (including the full logs):
One failure mode before the fix was:
error: Error: setup script specifies an absolute path:
/.../pytorch3d/pytorch3d/csrc/ext.cpp
setup() arguments must always be /-separated paths relative to the
setup.py directory, never absolute paths.
Expected behavior
Local source installs should work under modern packaging workflows without relying on legacy-only behavior.
Proposed fix
A minimal fix seems to be:
- add a minimal
pyproject.toml
- keep only core
project metadata there
- declare metadata still sourced from
setup.py as dynamic
- make extension source paths in
setup.py relative instead of absolute
🐛 Bugs / Unexpected behaviors
PyTorch3D has packaging compatibility issues under modern PEP 517 / PEP 660 local build workflows.
The main problems appear to be:
setup.pypasses absolute source paths to setuptools for the C++/CUDA extensionpyproject.tomlmetadata for modern build frontendsInstructions To Reproduce the Issue:
git diff) or code you wroteExpected behavior
Local source installs should work under modern packaging workflows without relying on legacy-only behavior.
Proposed fix
A minimal fix seems to be:
pyproject.tomlprojectmetadata theresetup.pyasdynamicsetup.pyrelative instead of absolute