Repository navigation
[pull] main from bazel-contrib:main - #681
Merged
Merged
Conversation
…st (#3982) When `bzlmod_lockfile_test` fails due to an out-of-date `MODULE.bazel.lock` file (e.g. under `--lockfile_mode=error`), Bazel previously output a generic failure message without indicating what diff changed or providing an updated lockfile artifact. This made debugging CI lockfile failures tedious and manual. To improve the developer experience: * On test failure, automatically run `bazel mod deps --lockfile_mode=update` to compute the expected lockfile changes. * Output a unified diff between the checked-in and expected `MODULE.bazel.lock` directly in the test failure logs along with actionable update commands. * Export the updated `MODULE.bazel.lock` and `MODULE.bazel.lock.diff` to `TEST_UNDECLARED_OUTPUTS_DIR` as build artifacts, allowing them to be downloaded directly in the Buildkite UI.
Previously only `--hash=sha256:` pins and `#sha256=` URL fragments were recognized. Pins using any other hash algorithm were silently dropped: the requirement was treated as hash-less, and in the pip fallback the hashes were stripped from the requirement line entirely, so the artifact was no longer verified against what was locked. Now a distribution digest is carried through the code as one canonical `<algo>:<hex digest>` string (the same shape as pip `--hash` and uv.lock `hash` values) for any `hashlib` algorithm: - a new `hash.bzl` module (single `hash` symbol) centralizes digest parsing, validation and conversion to SRI; - `parse_simpleapi_html` accepts any PEP 503 `#<algo>=<digest>` fragment and keys `whls`/`sdists` by the canonical digest; `sha256s_by_version` is renamed to `hashes_by_version`; - matching pins against the index is a direct dict lookup; when the index only advertises a different algorithm the requirement falls back to pip with the pins kept in the requirement line, so nothing installs unverified (pip verifies sha256/384/512 pins and rejects requirement lines pinned only with other algorithms); - `whl_library` gains an `integrity` attribute, and the extension now always passes the digest as an SRI `integrity` value instead of `sha256`, so the lock entries use one format for all algorithms; a malformed (non-hex) sha256/384/512 digest fails loudly at extension evaluation instead of silently disabling download verification; - the lock file facts store `<algo>:<digest>` values (`_FACT_VERSION` bumped to `v2`; old facts are refetched once); this also fixes the latent bug where `dist_filenames` was written keyed by URL but read back keyed by digest, so stored filenames were never found; - uv.lock `hash` values pass through for any algorithm instead of being mangled by a `sha256:` string replace. Repo names are unchanged for sha256 digests, and sha256 stays the preferred algorithm when a direct-URL requirement has several pins. Digests whose algorithm has no SRI form (e.g. md5) still match the index but are downloaded without downloader-side verification, with a warning. Fixes #3972 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Ignas Anikevicius <240938+aignas@users.noreply.github.com>
…3978) The gazelle Python extension picks its stdlib list by `python_version`. The select had no branch for `3.13` or `3.14`, so those configurations fell through to the `3.11` list and gazelle misses everything that changed since `3.11` (`3.14` added `compression.zstd`, `3.13` removed `telnetlib`). Bump `python_stdlib_list` to `stdlib-list` `0.12.0`, the first release shipping `lists/3.14.txt`, and add the two matching branches. Point `//conditions:default` at the newest list, so configurations with no matching branch stop landing on one four releases behind. Fetch the archive from the PyPI sdist rather than a GitHub release asset. Unlike `0.11.0`, `0.12.0` published no GitHub release assets. GitHub's auto-generated tag archives are not checksum-stable. PyPI never reuses an uploaded filename. ## BREAKING CHANGE: Gazelle plugin now requires rules_python 1.5.0 Bazel resolves every `select()` key at analysis time, so `is_python_3.14` must exist even for builds that never select it. `rules_python` generates that target from `MINOR_MAPPING`, which lists `3.14` starting in `1.5.0`. Older versions fail analysis, and that broke the `Gazelle: BCR` jobs on the first push. Two pins constrain resolution, and both move to `1.5.0`: the plugin's own `bazel_dep` (was `0.18.0`) and `gazelle/examples/bzlmod_build_file_generation` (was `1.4.0`). The example's `other_module` keeps its placeholder pin, which the root module overrides. ## Testing I added no automated coverage and would appreciate maintainer input on how, if at all, to test this. I didn't see an obvious way given the existing test infra.
…les (#3973) Building C/C++ Python extension modules currently requires manually configuring complex `cc_binary` or `cc_shared_library` targets and setting up platform, ABI3, and extension tags. The new `py_extension` rule provides a high-level Starlark API for compiling native extensions that integrate seamlessly with `rules_python` toolchains and `py_library` dependencies. At a high level, the implementation is fairly simple: Users can provide raw C/C++ `srcs`, which are put into a `cc_library`. That `cc_library` is then given to `cc_shared_library`, which performs the linking to create e.g. `libfoo.so`. That artifact is then given to a custom rule that handles rename it according to Python needs, e.g. `foo.abi3.so`. `cc_shared_library` is used because it provides various facilities to control creation of a shared library, namely, control over what is and isn't linked into the shared library. Credit to @rsartor-cmd for finishing the prototype, expanding test coverage, and verifying behavior. Closes #3283. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: rsartor-cmd <rsartor@google.com> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )