Merge branch 'aspect-build:main' into main

Author: daoanhkhoa123

.github/workflows/ci-workflows.yaml

@@ -59,3 +59,21 @@ jobs:
             - name: Test
               working-directory: ${{ matrix.workspace.path }}
               run: aspect test --task-key=test-${{ matrix.workspace.slug }}-${{ matrix.bazel.id }} ${{ matrix.bazel.flags }} -- //...
+            # Standalone scripts that drive bazel directly (e.g. asserting a
+            # build *fails*), so they can't be an `sh_test` under `//...` above.
+            - name: e2e standalone test.sh scripts
+              if: matrix.workspace.slug == 'e2e'
+              run: |
+                set -uo pipefail
+                status=0
+                for script in e2e/cases/*/test.sh; do
+                    echo "::group::${script}"
+                    if bash "${script}"; then
+                        echo "PASS: ${script}"
+                    else
+                        echo "FAIL: ${script}"
+                        status=1
+                    fi
+                    echo "::endgroup::"
+                done
+                exit "${status}"

MODULE.bazel

@@ -20,7 +20,7 @@ bazel_dep(name = "rules_python", version = "1.0.0")
 bazel_dep(name = "rules_shell", version = "0.6.1")
 bazel_dep(name = "tar.bzl", version = "0.10.1")
 bazel_dep(name = "with_cfg.bzl", version = "0.14.6")
-bazel_dep(name = "hermetic_launcher", version = "0.0.9")
+bazel_dep(name = "hermetic_launcher", version = "0.0.11")
 
 bazel_lib_toolchains = use_extension("@tar.bzl//tar:extensions.bzl", "toolchains")
 use_repo(bazel_lib_toolchains, "bsd_tar_toolchains")

README.md

@@ -368,16 +368,25 @@ the link target on a subset of binaries.
 
 ### Debugger Support (VSCode/PyCharm)
 
-Attach debuggers using `debugpy`:
+Attach DAP-compatible debuggers (VSCode, PyCharm, Neovim, etc.) using
+[debugpy](https://github.com/microsoft/debugpy). This requires a wrapper
+entrypoint that starts a debugpy listener before running your application —
+simply adding `debugpy` to `deps` is not enough.
 
-```starlark
-# In debug mode, wraps the binary with debugpy listener
-py_binary(
-    name = "app_debug",
-    srcs = ["main.py"],
-    deps = ["//:lib", "@pypi//debugpy"],
-    env = {"DEBUGPY_WAIT": "1"},  # Wait for IDE attachment
-)
+See the [complete debugger example](examples/debugger/) for a working
+setup, including a `py_debuggable_binary` macro that handles the wrapper
+generation automatically.
+
+Quick overview:
+
+```sh
+cd examples/debugger
+
+# Start with debugpy listener, wait for IDE to attach:
+DEBUGPY_WAIT=1 bazel run //:app
+
+# Release mode — no debugpy, runs directly:
+bazel run //:app --config=release
 ```
 
 VSCode `launch.json`:

docs/uv.md

@@ -286,6 +286,19 @@ over the dependency group targets in which that requirement is defined.
 Hub requirement targets are _incompatible_ with dependency group configurations in which the
 requirement in question is not defined.
 
+### Conditional dependencies and the empty target
+
+When a package is gated entirely behind an environment marker (e.g.
+`iniconfig; sys_platform == 'win32'`), the hub generates a `select()` alias
+with one arm per marker expression plus a `//conditions:default` arm that
+resolves to an internal empty `py_library`. This makes the `select()` total on
+all platforms: on non-Windows hosts the alias selects the empty library, which
+contributes no sources and no transitive deps, rather than failing analysis.
+
+If you inspect the generated BUILD files under the hub repository you will see
+targets named `empty` and `empty_whl` — these are intentional stubs and not a
+sign of a missing dependency.
+
 Each dependency group requirement is backed by a `whl_install` rule which chooses among
 prebuilt wheels listed in the lockfile to produce the equivalent of a
 `py_library`.

e2e/BUILD.bazel

@@ -82,12 +82,34 @@ write_source_files(
         # one constraint string.
         "snapshots/whl_install.bare_linux_wheels.grpcio.BUILD.bazel": "@whl_install__uv_bare_linux_wheels__grpcio__1_80_0//:BUILD.bazel",
 
+        # whl_install for the azure-core / azure-core-tracing-opentelemetry
+        # pair (cases/azure-core-tracing-overlap). Pins the namespace_dirs /
+        # regular_roots metadata emission for both sides of a regular
+        # package spanning wheels: azure-core's `regular_roots =
+        # ["azure/core"]` vs the tracing wheel's 4-dir namespace skeleton
+        # reaching down to `azure/core/tracing/ext`. A regression that
+        # stops emitting either attr silently degrades the venv's
+        # PySiteMerge trigger back to the broken `.pth`-only behaviour —
+        # the runtime test would catch that too, but the snapshot shows
+        # WHICH side of the metadata went missing.
+        "snapshots/whl_install.azure_overlap.azure_core.BUILD.bazel": "@whl_install__azure_core_tracing_import__azure_core__1_38_0//:BUILD.bazel",
+        "snapshots/whl_install.azure_overlap.azure_core_tracing_opentelemetry.BUILD.bazel": "@whl_install__azure_core_tracing_import__azure_core_tracing_opentelemetry__1_0_0b11//:BUILD.bazel",
+
         # whl_install for cryptography 46.0.5, which ships BOTH cp311-abi3
         # AND cp38-abi3 wheels for the same platforms. Pins the select_chain
         # arm mapping so a regression that drops source-specificity
         # disambiguation flips ~150 arms to the cp38 wheel in the diff.
         "snapshots/abi3_compat.whl_install.cryptography.BUILD.bazel": "@whl_install__abi3_compat__cryptography__46_0_5//:BUILD.bazel",
 
+        # whl_install for cffi 2.0.0, whose platform wheels each install a
+        # DIFFERENT C-extension top-level (`_cffi_backend.cpython-312-
+        # darwin.so` vs `...-x86_64-linux-gnu.so` vs win `.pyd`). Pins that
+        # top-level / console-script metadata is keyed per wheel file, so a
+        # regression back to unioning across platform wheels (which leaks an
+        # inactive wheel's package surface into the active configuration)
+        # shows up as the per-wheel dicts collapsing into one merged list.
+        "snapshots/abi3_compat.whl_install.cffi.BUILD.bazel": "@whl_install__abi3_compat__cffi__2_0_0//:BUILD.bazel",
+
         # @sdist_build for jpype1 with uv.override_package toolchains/env
         # ----------------------------------------------------------------
         # Covers the override_package -> repo-rule -> BUILD-template
@@ -106,16 +128,25 @@ write_source_files(
         # install_tree.short_path — stable across unrelated lockfile
         # churn; only added/removed/version-bumped wheels rotate them.
         #
-        # * pth_namespace_547 — keyed branch, minimal 2-contributor
-        #   namespace case (jaraco-*).
-        # * firebase_admin — keyed branch at scale (~8 google-*
-        #   namespace contributors); catches ordering / scale-only
-        #   regressions that the 2-line minimum can't.
+        # * pth_namespace_547 — minimal 2-contributor namespace case
+        #   (jaraco-*). The concrete per-entry namespace merge fully
+        #   covers both wheels, so the snapshot pins that neither
+        #   appears in the .pth fallback.
+        # * firebase_admin — namespace merge at scale (~8 google-*
+        #   contributors, nested google/cloud namespace); catches
+        #   ordering / scale-only regressions that the 2-wheel
+        #   minimum can't.
         # * wheel_root_pth — non-keyed branch via `py_unpacked_wheel`
         #   without `top_levels`; pins the `site.addsitedir(...)`
         #   shape so wheel-root `.pth` shims keep running.
+        # * pth_install_tree_fallback — two install_tree wheels colliding
+        #   on a top-level; the collision loser reaches `_format_imp`'s
+        #   site-packages branch and must emit a PLAIN escape path (not
+        #   `site.addsitedir`, which would re-run its already-projected
+        #   root `.pth`). Reverting that branch changes this snapshot.
         "snapshots/pth_namespace_547.test.venv.pth": "//cases/pth-namespace-547:test.venv.pth",
         "snapshots/firebase_admin.test_tool.venv.pth": "//cases/firebase-admin-import:test_tool.venv.pth",
         "snapshots/wheel_root_pth.venv.pth": "//cases/uv-include-group:wheel_root_pth_test.venv.pth",
+        "snapshots/pth_install_tree_fallback.venv.pth": "//cases/pth-install-tree-fallback:test.venv.pth",
     },
 )

e2e/MODULE.bazel

@@ -91,10 +91,13 @@ uv = use_extension("@aspect_rules_py//uv:extensions.bzl", "uv")
 
 # Per-case MODULE fragments. Each redeclares its own use_extension(...) proxies.
 include("//cases/arch-alias-marker:setup.MODULE.bazel")
+include("//cases/azure-core-tracing-overlap:setup.MODULE.bazel")
+include("//cases/azure-namespace-sibling:setup.MODULE.bazel")
 include("//cases/cross-repo-610:setup.MODULE.bazel")
 include("//cases/current-py-toolchain-bazel-env-896:setup.MODULE.bazel")
 include("//cases/firebase-admin-import:setup.MODULE.bazel")
 include("//cases/freethreaded-805:setup.MODULE.bazel")
+include("//cases/inactive-marker:setup.MODULE.bazel")
 include("//cases/interpreter-local-pyvenv-home:setup.MODULE.bazel")
 include("//cases/multi-project-hub:setup.MODULE.bazel")
 include("//cases/oci:setup.MODULE.bazel")
@@ -127,6 +130,7 @@ include("//cases/uv-pyproject-cases:setup.MODULE.bazel")
 include("//cases/uv-requirements-bzl:setup.MODULE.bazel")
 include("//cases/uv-sdist-fallback:setup.MODULE.bazel")
 include("//cases/uv-sdist-jdk-build:setup.MODULE.bazel")
+include("//cases/uv-sdist-mpicc:setup.MODULE.bazel")
 include("//cases/uv-sdist-native-build:setup.MODULE.bazel")
 include("//cases/uv-toolchain:setup.MODULE.bazel")
 include("//cases/uv-whl-install-output-group:setup.MODULE.bazel")

e2e/cases/azure-core-tracing-overlap/BUILD.bazel

@@ -0,0 +1,48 @@
+load("@aspect_rules_py//py:defs.bzl", "py_test")
+
+# Regression test: overlapping regular-package trees across wheels.
+#
+# azure-core owns `azure/core/` and `azure/core/tracing/` as regular
+# packages (both ship an `__init__.py`); azure-core-tracing-opentelemetry
+# installs `azure/core/tracing/ext/` into that same tree from a separate
+# wheel. Unlike the PEP 420 namespace cases (pth-namespace-547,
+# firebase-admin-import), regular packages don't merge `__path__` across
+# sys.path entries — venv assembly has to physically merge the
+# overlapping directories or `azure.core.tracing.ext` is unreachable.
+#
+# Reported by OpenAI: their `oai_otel_init` package hit
+#   ModuleNotFoundError: No module named 'azure.core.tracing.ext.opentelemetry_span'
+# under rules_py while the same pair works in any flat site-packages
+# install.
+#
+# Variants:
+#   :test       — py_test default (.pth strategy)
+#   :test_tool  — py_venv_test variant (symlink-forest venv)
+
+py_test(
+    name = "test",
+    srcs = ["test.py"],
+    dep_group = "azure-core-tracing-import",
+    main = "test.py",
+    deps = [
+        "@pypi_azure_core_tracing//azure_core",
+        "@pypi_azure_core_tracing//azure_core_tracing_opentelemetry",
+    ],
+)
+
+# Naming: `test_tool` (not `test_venv`) to avoid the tree-artifact /
+# internal-venv-dir prefix collision described in
+# cases/firebase-admin-import/BUILD.bazel.
+py_test(
+    name = "test_tool",
+    srcs = ["test.py"],
+    dep_group = "azure-core-tracing-import",
+    expose_venv = True,
+    isolated = False,
+    main = "test.py",
+    python_version = "3.11",
+    deps = [
+        "@pypi_azure_core_tracing//azure_core",
+        "@pypi_azure_core_tracing//azure_core_tracing_opentelemetry",
+    ],
+)

e2e/cases/azure-core-tracing-overlap/pyproject.toml

@@ -0,0 +1,20 @@
+[project]
+name = "azure-core-tracing-import"
+version = "0.0.0"
+# azure-core ships `azure/core/` as a REGULAR package (it has an
+# `__init__.py`, only the `azure/` top level is a PEP 420 namespace).
+# azure-core-tracing-opentelemetry contributes `azure/core/tracing/ext/`
+# INSIDE that regular package from a separate wheel. Regular packages
+# don't merge `__path__` across sys.path entries, so this pair only
+# works if venv assembly physically merges the overlapping directory
+# trees — the namespace `.pth` machinery cannot help here.
+requires-python = ">=3.11"
+dependencies = [
+    # `build` + `setuptools` match the hub's default_build_dependencies
+    # declared in //MODULE.bazel. The uv extension expects every project
+    # lockfile to be able to resolve them.
+    "build",
+    "setuptools",
+    "azure-core==1.38.0",
+    "azure-core-tracing-opentelemetry==1.0.0b11",
+]

e2e/cases/azure-core-tracing-overlap/setup.MODULE.bazel

@@ -0,0 +1,20 @@
+"""Regression: overlapping regular-package trees across wheels.
+
+azure-core owns the regular package `azure/core/` (and
+`azure/core/tracing/`); azure-core-tracing-opentelemetry installs
+`azure/core/tracing/ext/` into that same tree from a separate wheel.
+"""
+
+uv = use_extension("@aspect_rules_py//uv:extensions.bzl", "uv")
+uv.declare_hub(hub_name = "pypi_azure_core_tracing")
+uv.project(
+    hub_name = "pypi_azure_core_tracing",
+    lock = "//cases/azure-core-tracing-overlap:uv.lock",
+    pyproject = "//cases/azure-core-tracing-overlap:pyproject.toml",
+)
+use_repo(uv, "pypi_azure_core_tracing")
+
+# Exposed so e2e/BUILD.bazel can snapshot the namespace_dirs / regular_roots
+# metadata the whl_install repo rule emits for this overlapping pair.
+use_repo(uv, "whl_install__azure_core_tracing_import__azure_core__1_38_0")
+use_repo(uv, "whl_install__azure_core_tracing_import__azure_core_tracing_opentelemetry__1_0_0b11")

e2e/cases/azure-core-tracing-overlap/test.py

@@ -0,0 +1,65 @@
+"""Regression: overlapping regular-package trees across wheels.
+
+azure-core 1.38.0 ships `azure/core/` and `azure/core/tracing/` as
+REGULAR packages (each has an `__init__.py`); only the `azure/` top
+level is a PEP 420 namespace. azure-core-tracing-opentelemetry
+1.0.0b11 ships `azure/core/tracing/ext/opentelemetry_span.py` — a
+subpackage nested inside a regular package owned by a *different*
+wheel.
+
+Regular packages do not merge `__path__` across sys.path entries, so
+the namespace `.pth` + addsitedir machinery (see
+cases/firebase-admin-import, cases/pth-namespace-547) cannot make
+`azure.core.tracing.ext` reachable: once Python resolves
+`azure.core.tracing` to azure-core's directory, the `ext/` directory
+contributed by the other wheel is invisible unless venv assembly
+physically merges the two trees the way a flat `pip install` into one
+site-packages would.
+
+Reported by OpenAI from their `oai_otel_init` package, which uses this
+exact Azure package pair.
+"""
+
+import sys
+
+
+def test_azure_core_tracing_ext_import():
+    # The failing import from the report: requires `ext/` (from
+    # azure-core-tracing-opentelemetry) to be visible inside the
+    # `azure.core.tracing` regular package (from azure-core).
+    from azure.core.tracing.ext.opentelemetry_span import OpenTelemetrySpan
+
+    assert OpenTelemetrySpan is not None
+
+
+def test_azure_core_still_intact():
+    # The merge must not break azure-core's own modules next to the
+    # grafted `ext/` directory.
+    from azure.core.settings import settings
+    from azure.core.tracing import SpanKind
+
+    assert settings is not None
+    assert SpanKind is not None
+
+
+def test_azure_core_tracing_is_regular_package():
+    """Guard the premise of this test case.
+
+    If a future azure-core converts `azure.core.tracing` into a
+    namespace package, this case would silently degrade into a
+    duplicate of the pth-namespace-547 coverage. Fail loudly so the
+    fixture gets re-pointed at another overlapping pair.
+    """
+    import azure.core.tracing
+
+    assert azure.core.tracing.__file__ is not None, (
+        "azure.core.tracing should be a regular package with __init__.py"
+    )
+
+
+if __name__ == "__main__":
+    test_azure_core_tracing_ext_import()
+    test_azure_core_still_intact()
+    test_azure_core_tracing_is_regular_package()
+    print("PASS: azure.core.tracing.ext imports correctly")
+    sys.exit(0)