pep517_native_whl (via uv.override_package(env = {...}, toolchains = [...])) expands $(VAR) make-variables in the build action's env from the toolchains it depends on. Those values are workspace-relative paths: a dependency's include dir expands to something like bazel-out/.../include, which resolves from the execroot but not from the PEP 517 backend's cwd. python -m build runs the backend with its cwd inside the unpacked sdist worktree (build_helper invokes it with cwd=<worktree>), so a workspace-relative -Ibazel-out/.../include dangles and the build fails with fatal error: '<header>' file not found, or the link can't find the dep archive.

Add a $(EXECROOT) make-variable to anchor those paths, e.g. -I$(EXECROOT)/$(DEP_INC). The execroot isn't known at analysis time, so $(EXECROOT) expands to a marker that build_helper replaces with the absolute execroot at build time, before the chdir. It's a plain text substitution rather than flag parsing, so it works for any env var and any flag form (-I, -L, -Wl,-rpath, -framework, CC, ...).

EXECROOT is reserved for this. If a toolchain in toolchains already exports it, $(EXECROOT) would expand to that value instead of the marker and silently skip anchoring, so analysis now fails with a message pointing at the collision rather than producing a confusing compile error later.

I went with an opt-in anchor rather than having build_helper detect and absolutize path-bearing flags itself: it can't reliably tell an execroot-relative path from a symbol/framework name or a worktree-relative path, can't cover every flag syntax, and would risk mangling values it doesn't need to touch.

More generally, what might be missing is some notion of a deps analog to cargo_build_script that can inspect a CcInfo provider and get the CcInfo.linking_context. This is a much bigger design question if were to be offered first-class since setuptools handles the linking, and this would all have to get flattened into LDFLAGS/extra_link_args.

Regression test

Adds uv/private/pep517_whl/tests/native_dep: a cc_library whose include dir and static archive are surfaced as make-vars (standing in for override_package(toolchains=, env=)), consumed by a small PEP 517 backend that compiles a C extension against them.

Split into a red/green pair. The test commit wires the env as plain -I$(DEP_INC) / $(DEP_LIB_A), which fails today because the backend compiles with an execroot-relative -I that dangles after the chdir. The fix commit adds $(EXECROOT) and switches the test to -I$(EXECROOT)/$(DEP_INC).

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: yes ($(EXECROOT) documented on the override_package(env=) tag and the pep517_native_whl env attr)
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: yes

uv.override_package(env = {...}) now supports a $(EXECROOT) make-variable to anchor workspace-relative paths for native sdist builds (e.g. "CPPFLAGS": "-I$(EXECROOT)/$(DEP_INC)"), so they survive the PEP 517 backend's chdir into the sdist worktree.

Testing

• bazel test //uv/private/pep517_whl/tests/native_dep:native_dep_env_test
• buildifier --mode=check uv/private/pep517_whl/rule.bzl