Modern PEP 517/660 local builds fail due to packaging metadata and absolute extension source paths

Bugs / Unexpected behaviors

PyTorch3D has packaging compatibility issues under modern PEP 517 / PEP 660 local build workflows.

The main problems appear to be:

1. setup.py passes absolute source paths to setuptools for the C++/CUDA extension
2. the project does not provide minimal pyproject.toml metadata for modern build frontends

Instructions To Reproduce the Issue:

1. Any changes you made (git diff) or code you wrote

No source changes are required to reproduce the original failure.

1. 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

1. 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:

1. add a minimal pyproject.toml
2. keep only core project metadata there
3. declare metadata still sourced from setup.py as dynamic
4. make extension source paths in setup.py relative instead of absolute