What happened?
What happened:
In a multi-module bzlmod workspace where the test target itself lives in an external repo (each component is its own module brought in with local_path_override), every relative entry in the generated _aspect.pth uses seven ../:
# Generated by Aspect py_binary
# Contains relative import paths to non site-package trees within the .runfiles
../../../../../../../aspect_rules_py+/py/private/pytest_shard
../../../../../../../sonic-py-swsssdk+/src
../../../../../../../sonic-swss-common+/pybind
But the venv's site-packages is only 5 levels deep inside the runfiles tree (/+/./lib/python3.13/site-packages), so 7 × .. overshoots the runfiles root by two and lands in /bin/external/. That is a different namespace: runfiles is a flat per-repo layout, while bin/external/ is the output-tree layout that only contains repos which actually produce outputs. Consequences:
Source-only external repos have no bin/external// at all, so those entries never resolve — sandboxed or with --spawn_strategy=local.
Repos with generated outputs resolve only outside the sandbox, where the path happens to exist in the real output tree.
Because CPython's site silently ignores .pth lines pointing at non-existent directories, there is no diagnostic; the symptom surfaces later as a ModuleNotFoundError for a dependency that is declared and is present in runfiles.
What expect:
_aspect.pth entries resolve to // — matching the header comment rules_py writes itself — regardless of whether the target lives in @_main or in an external module, and regardless of spawn strategy. Re-anchoring the same entries against TEST_SRCDIR in a custom entrypoint makes the identical target pass both sandboxed and non-sandboxed.
Version
Output of bazel --version:
bazel 8.6.0
Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file:
bazel_dep(name = "aspect_rules_py", version = "1.11.7") — bzlmod only, no WORKSPACE. Rules in use: py_venv_test from @aspect_rules_py//py/unstable:defs.bzl, py_pytest_main from @aspect_rules_py//py:defs.bzl, third-party deps via uv.declare_hub / uv.project from @aspect_rules_py//uv/unstable:extension.bzl. The workspace shape that matters: first-party Python libraries are separate bzlmod modules brought in with local_path_override, so test targets live in external repos rather than @_main.
Language(s) and/or frameworks involved:
Python 3.13 (hermetic toolchain), pytest. The dependency closure mixes source-only py_library targets from sibling modules with one SWIG-generated C-extension py_library — both kinds of .pth entry are affected.
How to reproduce
Any other information?
No response
What happened?
What happened:
In a multi-module bzlmod workspace where the test target itself lives in an external repo (each component is its own module brought in with local_path_override), every relative entry in the generated _aspect.pth uses seven ../:
# Generated by Aspect py_binary
# Contains relative import paths to non site-package trees within the .runfiles
../../../../../../../aspect_rules_py+/py/private/pytest_shard
../../../../../../../sonic-py-swsssdk+/src
../../../../../../../sonic-swss-common+/pybind
But the venv's site-packages is only 5 levels deep inside the runfiles tree (/+/./lib/python3.13/site-packages), so 7 × .. overshoots the runfiles root by two and lands in /bin/external/. That is a different namespace: runfiles is a flat per-repo layout, while bin/external/ is the output-tree layout that only contains repos which actually produce outputs. Consequences:
Source-only external repos have no bin/external// at all, so those entries never resolve — sandboxed or with --spawn_strategy=local.
Repos with generated outputs resolve only outside the sandbox, where the path happens to exist in the real output tree.
Because CPython's site silently ignores .pth lines pointing at non-existent directories, there is no diagnostic; the symptom surfaces later as a ModuleNotFoundError for a dependency that is declared and is present in runfiles.
What expect:
_aspect.pth entries resolve to // — matching the header comment rules_py writes itself — regardless of whether the target lives in @_main or in an external module, and regardless of spawn strategy. Re-anchoring the same entries against TEST_SRCDIR in a custom entrypoint makes the identical target pass both sandboxed and non-sandboxed.
Version
Output of bazel --version:
bazel 8.6.0
Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file:
bazel_dep(name = "aspect_rules_py", version = "1.11.7") — bzlmod only, no WORKSPACE. Rules in use: py_venv_test from @aspect_rules_py//py/unstable:defs.bzl, py_pytest_main from @aspect_rules_py//py:defs.bzl, third-party deps via uv.declare_hub / uv.project from @aspect_rules_py//uv/unstable:extension.bzl. The workspace shape that matters: first-party Python libraries are separate bzlmod modules brought in with local_path_override, so test targets live in external repos rather than @_main.
Language(s) and/or frameworks involved:
Python 3.13 (hermetic toolchain), pytest. The dependency closure mixes source-only py_library targets from sibling modules with one SWIG-generated C-extension py_library — both kinds of .pth entry are affected.
How to reproduce
Any other information?
No response