feat: Rule for C extensions by rsartor-cmd · Pull Request #1 · rsartor-cmd/rules_python

rsartor-cmd · 2026-06-23T04:50:10Z

This PR introduces a new rule, py_extension, used for building C extensions. For now, the macro and rule are sufficiently developed for py_extension_test to build and pass, though work remains to be done for them to be production-ready.

bazel-contrib#3283

…#3795) Rules that execute a py_runtime interpreter in an action need the interpreter executable together with its runfiles metadata. The existing PyRuntimeInfo fields identify the interpreter file and runtime files, but do not preserve the target's FilesToRunProvider for executable interpreter targets. Add PyRuntimeInfo.interpreter_files_to_run for runtimes created from an executable interpreter target, and validate that direct provider construction keeps the FilesToRunProvider executable aligned with the interpreter field. Direct file interpreters and platform runtimes continue to leave this field unset, preserving existing py_runtime behavior. Document the new public provider field and add focused analysis-test coverage for executable, file-only, platform, and invalid constructor cases. One example is [rules_pycross](https://github.com/jvolkman/rules_pycross) wheel building with an in-build executable Python runtime. pycross needs to run the selected Python interpreter in an action, but PyRuntimeInfo previously exposed only the interpreter File and runtime files, not the interpreter target's FilesToRunProvider. For executable in-build runtimes, the FilesToRunProvider is the Bazel-native handle that carries both the executable and the runfiles metadata needed to stage it as an action tool. Exposing it lets pycross consume the runtime interpreter directly for wheel-build actions instead of reconstructing or approximating the interpreter's runtime closure from separate fields. Co-authored-by: Richard Levasseur <richardlev@gmail.com>

Update changelog and version markers --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Currently, we update the change log directly when user-visible changes are made. This works, but makes backporting patches into release branches prone to unnecessary conflicts. These conflicts can sometimes be quite confusing, making it easy to accidentally merge incorrect content. Instead, what we can do is keep track of an upcoming release's change log entries in separate files under the `news/` directory. When creating a release, all the news entries are assembled into a section in the change log and the news entries deleted. When backporting a change, after cherry picking, the news entries are merged into the release's change log section.

…trib#3832) Under `bazel coverage`, coverage.py raises `NoDataError` from `lcov_report()` when no instrumented Python code was executed, instead of writing an (empty) report. This error currently propagates out of the coverage bootstrap and fails an otherwise passing test. This is common and benign in a few setups: - a `py_binary` that only spawns another process and runs no Python itself - a test whose instrumented sources happen not to execute any Python **Before:** `bazel coverage //a:test` fails with `coverage.exceptions.NoDataError` even though `bazel test //a:test` passes. **After:** the `NoDataError` is caught and the empty report is skipped, so the test result is unchanged by whether coverage data happened to be collected. This mirrors the reporter's suggestion in bazel-contrib#2762 to "ignore the return code of `coverage lcov`", applied in-process. As noted on the original report and in bazel-contrib#3823, there is no in-repo harness for exercising real coverage collection, so this change does not add an automated test. Fixes bazel-contrib#2762 --------- Co-authored-by: Richard Levasseur <richardlev@gmail.com>

…bazel-contrib#3828) Resolve `pip.parse(experimental_index_url = ...)` through `envsubst` before checking whether the experimental index-url code path should be enabled. Previously, an unsubstituted template like `$RULES_PYTHON_PIP_INDEX_URL` is a non-empty string and therefore truthy, so `_set_get_index_urls` enabled the experimental index-url mode even when the env var was unset or expanded to empty. With this change, the value is expanded first (using `pip_attr.envsubst` and `module_ctx.os.environ.get`) and the truthiness check runs against the resolved string, matching the behavior users expect when they gate the index URL on an env var. --------- Co-authored-by: Richard Levasseur <richardlev@gmail.com>

1. Refactored patch_whl.bzl — Extracted fix_record_content() as a public pure function (no rctx dependency) so it can be unit tested directly. 2. Unit tests (patch_whl_tests.bzl) — 5 new rules_testing tests for fix_record_content: - Adds missing files to RECORD - Returns None when nothing is missing - Preserves quoting style of existing entries - Skips excluded files (INSTALLER, RECORD*, REQUESTED) - Skips .whl files 3. Integration test (patch_whl_patch_test.py) — End-to-end test that: - Creates a wheel from testdata/pkg/ via whl_from_dir_repo - Applies a patch via whl_library(whl_patches=...) - Verifies pkg.PATCHED is True (was False) and pkg.DATA is unchanged The integration test follows the established pattern: test data in tests/pypi/patch_whl/testdata/, registered in internal_dev_deps.bzl, wired into MODULE.bazel, and built as a py_test. All 205 pypi tests pass. With this we can potentially more easily separate whl and sdist path ways. --------- Co-authored-by: Richard Levasseur <richardlev@gmail.com>

…APIs (bazel-contrib#3835) Currently, `VenvSymlinkEntry` and `VenvSymlinkKind` are defined in the private `python/private/py_info.bzl` file, making them inaccessible to users who want to programmatically define virtual environment symlinks when using `PyInfo` (or at the least, having to load private file paths). To fix this, we load and re-export both symbols in the public `python/py_info.bzl` file. Along the way * Adds `VenvSymlinkEntryBuilder` to allow fluent construction of symlink entries via PyInfoBuilder. * Adds `features.loadable_symbols` to allow programmatic detection of these public symbols.

Currently, the generated changelog has a broken link to the news directory. Since we can process the files as part of docgen, fix the broken link by rendering the news as one would see it for a release. Along the way... * Delete defunct unreleased template handling, as we've switched to news file assembly instead.

Enable bazel-diff to improve CI performance by skipping targets that aren't affected by a PR

This PR fixes the CI breakage on main where bazel-diff ran in plain query mode, ignoring target_compatible_with and attempting to run platform-incompatible tests. It re-introduces the java wrapper to inject cquery mode targeting only non-manual tests, and re-applies the visibility fix.

…-contrib#3840) This PR disables the bazel-diff target filtering to repair the CI. Since we make heavy use of target_compatible_with to restrict tests to specific platforms, and Bazel CI's bazel-diff integration isn't able to handle those.

Implicit `__init__.py` creation is deprecated and will be disabled by default in a future release. We need to warn users when their targets rely on this behavior so they can transition to explicit `__init__.py` files before the default changes and their builds break. Work towards bazel-contrib#2945

…template (bazel-contrib#3842) Align the Windows path resolution in the site initialization template with the bootstrap template to prevent flaky platform lookup errors on Windows 2022. This is achieved by wrapping the win32 version retrieval in a retrying loop. Fixes bazel-contrib#3721

Fixes venv output naming for `py_binary` and `py_test` targets whose names contain path separators. Before this change, the venv output prefix was derived from the executable basename. Distinct targets such as `//:foo/tool` and `//:bar/tool` both have executable basename `tool`, so they could both declare the same package-relative venv output directory: ```text bazel-out/.../bin/_tool.venv ``` After this change, the venv output prefix is derived from the full target name with `/` replaced by `_`, so those targets use separate venv output directories such as: ```text _foo_tool.venv _bar_tool.venv ``` Added regression coverage for slash-named executable targets in the shared `py_binary` / `py_test` base-rule tests. Fixes bazel-contrib#3844

This introduces workflows and tools to automate releases. The basic idea it to have an issue with tasks, and workflows invoke tools that parse and update the tasks in the issue. The basic release steps are: 1. Prepare a release (update changelog via PR) 2. Create a release branch after preparation 3. Backport changes into the release branch 4. Tag RCs 5. Promote to final Each step has a workflow. For now, most of the workflows require a manual trigger, to help prevent workflows from running wild as we flush out bugs and edge cases. The workflows almost entirely delegate to the `release` tool. There's basically one command per workflow. This makes it easy to encode specialized logic and run it locally for testing or reproduction.

…ontrib#3846) This file was not intended to be tracked in the repository, so it has been removed.

This implements a pypi hub that is the union of all pypi hubs. The basic design is: * The `pip` extension _always_ creates a `@pypi` repo unless the name is already taken by another hub definition. * The `--pypi_hub` flag dispatches to one of the hubs. If not set, then it uses a default one (first, or as configured) The set of packages and targets the unified hub exposes is a union of all other hubs. If the unified hub routes to a hub that doesn't support such a target, then it points to a target that fails at execution time. This is to allow query and cquery to work even if some targets don't exist in some hubs.

The strategy for this is: * First add a way for us to create a `uv.lock` file from the `lock` rule. * Then add a `uv.lock` reader via the bazel toml parser. * Then plug the code into the `parse_requirements` function so that we can reuse the most of code already there. * Add some sample docs for the `uv.lock`. Extra things that we could do: * Call the PyPI index to understand if the packages are yanked or not - lock file does not have that information. * Read the `pyproject.toml` file to get the index values for each package. * Add e2e tests from `rules_py` test suite. Closes bazel-contrib#3557 Work towards bazel-contrib#2787 --------- Co-authored-by: Richard Levasseur <richardlev@gmail.com> Co-authored-by: Richard Levasseur <rlevasseur@google.com>

…ntrib#3849) Add a workspace-specific agent rule to ensure that new conversations/sessions and branches are always based on the latest upstream code to avoid using outdated code states. This comes about after having several sessions go haywire at the start because they didn't see the latest changes.

…trib#3859) Create a workflow for lighter weight PR checks. These just check basic things about a PR, e.g. markers to prevent submit, blocking files that shouldn't be checked in.

To make it easier to manage the many bzl_library targets we have, switch to using gazelle to do so. Unfortunately, gazelle has strong opinions about target names: it forces `{foo}` names and doesn't allow `{foo}_bzl` names. Trying to make it do so requires quite a bit of gazelle directives. Instead, rename all the internal targets, but create aliases for public targets. Along the way... * Delete unused py_args.bzl * Add agent rule to avoid inappropriate copyright * Add a skill for creating rules

…ib#3861) The pr-metadata-checks workflow was failing because gh pr diff requires a git repository context when run without target repository information. We now explicitly pass the repository using the --repo flag, allowing the job to run successfully without needing a full repository checkout.

## Summary Add an `extract_needs_chmod` config flag that controls whether `chmod` is run after extracting wheel files. The flag is `False` for Bazel >= 8.6 (where the fix for file permissions is built into Bazel) and `True` for older versions. Move `_maybe_fix_permissions` from `whl_extract.bzl` into `repo_utils.bzl` and have `_extract` call it conditionally based on the config flag. This ensures both `whl_extract` and `patch_whl` benefit from the chmod fix when needed. Whilst at it migrate tests to common mocks. Fixes bazel-contrib#3585 Closes bazel-contrib#3860

Make the check run on edit so that it can detect adding/removing of the special marker text.

This is no longer used starting when we enabled pipstar by default and did a code cleanup where Python is no longer used to extract the wheels. Split from bazel-contrib#3856

…azel-contrib#3866) This change refactors the release promotion tool to ensure all pre-conditions are verified before making any modifications and automates post-promotion tracking updates. It also fixes a bug where the tool incorrectly assumed 'v' prefixes when identifying the latest release candidate and computing the final version tag.

…d-backports accept hashtag and url refs (bazel-contrib#3897) Currently, backports must be manually added to the release tracking issue. This change automates the process by allowing maintainers to comment `/backport` on a PR to add it to the active release's backport checklist, and automatically triggering the backport processing when the PR is merged. To support this, the following changes were made: - Added `add-backports` subcommand to the release tool to append PRs to the tracking issue. - Added `on-pr-merged` subcommand to verify `/backport` comment, find the tracking issue, and process backports. - Created `release_add_backports.yaml` reusable workflow to run the `add-backports` subcommand. - Updated `on_comment.yaml` to parse `/backport` comments on PRs and trigger the addition. - Created `on_pr_closed.yaml` to detect merged PRs and run the `on-pr-merged` subcommand. - Added unit tests for the new subcommands and URL resolution.

…ntrib#3898) chore(release): fix promote_rc arguments and align comments `promote_rc.py` was calling `Git.fetch` with `refspec` keyword argument which was not supported by `Git.fetch` signature, leading to fatal errors. The release promotion comment format was different from the release candidate creation comment format, leading to inconsistency. - Added `refspec` argument support to `Git.fetch` in `git.py`. - Added `sys.argv` printing at startup in `release.py` for debugging. - Updated `promote_rc.py` comment body to match `create_rc.py` style and added necessary helper variables. - Updated `git_test.py` to test `Git.fetch` with `refspec`. - Updated `promote_rc_test.py` to match the new comment format.

…l-contrib#3899) Currently, the `promote-rc` command fails because it calls `Git.get_commit_sha` with an invalid keyword argument `remote_ref`. Additionally, we want to align argument passing in the workflow with the `=` style. To fix this: - Remove the invalid `remote_ref` keyword argument from `Git.get_commit_sha` call in `promote_rc.py`. - Update `promote_rc_test.py` mock assertions to match the corrected call. - Update `release_promote_rc.yaml` to pass `--issue` and `--remote` arguments using `=`.

…w to finish publishing (bazel-contrib#3900) Why: The tagging done by promote_rc doesn't trigger the on-tag trigger of the publish workflow (due to GITHUB_TOKEN restriction). How: - Modified promote_rc.py to output the promoted version to GITHUB_OUTPUT. - Modified release_promote_rc.yaml to capture this version and chain the release_publish workflow. - Added unit tests for GITHUB_OUTPUT writing in promote_rc_test.py.

The 2.2 release was completed, but the changelog updates and news file deletions were only performed on the release branch. We need to sync these changes back to main so that they are reflected in the unreleased state and future releases.

…kports (bazel-contrib#3903) This PR implements the changes to sync both CHANGELOG.md and version next markers to the `main` branch when backports are processed. Key changes: - Adds git `diff`, `apply`, and `apply_check` helpers to the release tool. - Updates the GitHub helper to support custom PR base and auto-merge. - Updates `changelog_news.py` to support selective news merging and correct semver-sorted insertion, while preserving the static `Unreleased` section. - Updates `process_backports.py` to collect version marker diffs during cherry-pick, check if they apply cleanly to main, apply them, and report any failures in the PR body. These changes ensure that the `main` branch's changelog and version markers remain in sync with the release branch during the backport process.

…rib#3904) This news file was left over from a previous release process and is no longer needed. Removed the file `news/process-backports-before-rc.changed.md`.

Quote the 'if' condition in release_create_release_branch.yaml to fix YAML syntax error.

This is so that the purl can be generated correctly and we pass the right index_url parameter to the whl_library file. Work towards bazel-contrib#1975 --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Richard Levasseur <richardlev@gmail.com>

Free gemini code assist is being disabled in a few weeks, and I've found the ai reviews useful enough to want to keep them, so replace it with a custom agent based upon the antigravity sdk that does code reviews. I've added a Gemini API key to the project for it to use. It's free-tier level quota, so is relatively limited, hence reviews are limited to project maintainer PRsor when a maintainer comments `/review`.

…forward it to the generated `py_binary` (bazel-contrib#3865) As stated in bazel-contrib#3858, the `compile_pip_requirements` macro accepts a `data` attribute, but this attribute is not forwarded to the internal `py_binary` target generated for the `.update` target. As a result, using `$(location :pip_cert)` inside `extra_args` fails during analysis because the generated `py_binary` does not declare `:pip_cert` as a prerequisite. Before: ``` ERROR: /.../BUILD.bazel:8:25: in args attribute of py_binary rule //:requirements.update: label '//:pip_cert' in $(location) expression is not a declared prerequisite of this rule. Since this rule was created by the macro 'pip_compile', the error might have been caused by the macro implementation ERROR: /.../BUILD.bazel:8:25: Analysis of target '//:requirements.update' (config: 7f8856b) failed ERROR: Analysis of target '//:requirements.update' failed; build aborted ``` After: ``` INFO: Analyzed target //:requirements.update (87 packages loaded, 4078 targets configured). INFO: Found 1 target... Target //:requirements.update up-to-date: bazel-bin/requirements.update INFO: Elapsed time: 6.240s, Critical Path: 0.11s INFO: 1 process: 11 action cache hit, 1 internal. INFO: Build completed successfully, 1 total action INFO: Running command line: bazel-bin/requirements.update '--src=rules_python_pip_parse_example/requirements.in' rules_python_pip_parse_example/requirements_lock.txt //:requirements '--resolver=backtracking' --allow-unsafe --generate-hashes '--cert=./pip.cert' ``` Closes bazel-contrib#3858 --------- Co-authored-by: Ignas Anikevicius <240938+aignas@users.noreply.github.com> Co-authored-by: Richard Levasseur <richardlev@gmail.com>

…bazel-contrib#3918) Currently, the automated PR review workflow requires a diff review comment (`pull_request_review_comment`) to trigger on-demand reviews via `/review`. This prevents maintainers from triggering reviews from regular conversation comments on pull requests. To fix, change the event trigger from `pull_request_review_comment` to `issue_comment`, ensure the event is on a pull request by checking `github.event.issue.pull_request != null`, and check out `refs/pull/$NUMBER/head` so the PR branch is retrieved during comment events. * Also checks `\r\n/review` when parsing comment body for multiline `/review` commands.

…azel-contrib#3921) Currently, running `antigravity_review.py` with `uv run` fails because it lacks PEP 723 dependency metadata and passes `system_instructions` to `Agent` instead of `LocalAgentConfig`. Also, `skills_paths` points to the skill directory rather than the `SKILL.md` file. To fix, add inline PEP 723 script metadata declaring dependencies, pass `system_instructions` to `LocalAgentConfig`, and target `SKILL.md` directly in `skills_paths`.

We had to disable the `sphinxdocs` persistent worker in Pigweed (https://pwbug.dev/493749800) because the cache invalidation logic seemed incomplete with regards to Git branches. E.g. in branch `feat` you create a new doc `foo.rst`. You switch back to branch `main` and try to build Sphinx, but Sphinx warns about needing to ignore unreadable document `foo.rst`. Because Pigweed builds Sphinx with `--fail-on-warning` this would break our docs build. This PR adds the bug fix and also starts a suite of tests that will be focused on persistent worker correctness. --------- Co-authored-by: Richard Levasseur <richardlev@gmail.com>

…bazel-contrib#3920) Currently, several internal macros, toolchain definitions, and config settings either hardcode \`["//visibility:public"]\` or define private copies like \`_NOT_ACTUALLY_PUBLIC\`. This scatters visibility workarounds across the codebase and makes developer intent unclear. To clean this up, transition internal rules across \`python/private\` to use \`NOT_ACTUALLY_PUBLIC\` from \`python/private/visibility.bzl\`, and update corresponding \`bzl_library\` dependencies to match.

…e rule builders (bazel-contrib#3919) `create_executable_rule_builder()` (used by `py_binary_rule_builder()` / `py_test_rule_builder()`, the public `python/api/executables.bzl` API) bundles three implicit attrs whose defaults point at private targets under `//python/private`: `build_data_writer`, `debugger_if_target_config`, and `uncachable_version_file`. These targets had no explicit visibility, so they inherited the package's `default_visibility` (`//:__subpackages__`), which only covers packages inside the rules_python repo itself. Because the builder API is designed to let external modules call `rule()` themselves (via `builder.build()`), Bazel checks visibility of these attr defaults from the *calling* module's package, not from rules_python's. Any external repo constructing a rule via `py_binary_rule_builder()` / `py_test_rule_builder()` therefore fails at analysis time with a visibility error. This has been broken since the builder API's introduction; there's prior art in this same file for exactly this situation (e.g. `stage1_bootstrap_template`, among others) Co-authored-by: Richard Levasseur <richardlev@gmail.com>

…azel-contrib#3922) Currently, `LocalAgentConfig` only configures a single default model without an explicit endpoint attached when passing `ModelTarget` objects, which causes startup errors (`must have an endpoint configured`) or rate-limit failures when quota runs short. To fix, import `GeminiAPIEndpoint` and `ModelTarget`, create an explicit endpoint (`GeminiAPIEndpoint()`), and configure a prioritized multi-model cascade across all major Gemini 3 and Gemini 2 models so the agent automatically falls back to whichever model has open quota and full function calling capabilities.

...and sycophantic toasters are bad collaborators

…el-contrib#3851) This builds on the existing `py-extension` branch. It adds support for platform and abi tags in the resulting library filename. The `:py_extension_test`, `:py_extension_analysis_tests`, and `:py_limited_api_tests` test targets in `//tests/cc/py_extension` now build and pass. Relates to bazel-contrib#3283

…tension (bazel-contrib#3875) Per feedback from bazel-contrib#3851, this PR re-works the platform detection logic to rely on platform constraints instead of the Python runtime/toolchain. ### Description This PR contains updates to the experimental `py_extension` implementation. It re-works the platform tag detection to rely on modern platform constraints, and refactors the compilation and linking mechanism to delegate to Bazel's native `cc_shared_library` and `cc_library` rules. This PR targets the main repository's `py-extension` branch (not `main`). ### Key Changes #### 1. Platform Tag & ABI Tag Derivation * **Introduced `abi_tag` to `PyCcToolchainInfo`**: Added the `abi_tag` field to the `PyCcToolchainInfo` provider, populated by the `py_cc_toolchain` rule. It defaults to deriving the tag from `python_version` (e.g. `cpython-311`) for backward compatibility. * **Constraint-Based Detection**: Replaced legacy parsing of `cc_toolchain` CPU names with direct lookup in rules_python's central `PLATFORMS` registry using platform constraints. * **Limited API Configuration**: Updated how limited API (`.abi3.so`) suffixes are appended based on the toolchain configuration. #### 2. Compilation & Linking Delegation (Refactor to `cc_shared_library`) * **Macro Fusion**: Replaced the custom linking logic in the `py_extension` rule with a macro of the same name. It now accepts C/C++ source/header files directly (`srcs`, `hdrs`, `copts`, `defines`), implicitly wrapping them in a private `cc_library` under the hood. * **Consolidated Attributes**: Consolidated static linkage under standard `deps` (removing the redundant `static_deps` attribute) and aligned linker arguments with `cc_shared_library`'s `user_link_flags`. * **Wrapper Rule (`_py_extension_wrapper`)**: Added a lightweight, private rule that wraps the `cc_shared_library` output to: * Query the Python toolchain for platform/ABI tags to resolve PEP 3149 compliant filenames (e.g. `.cpython-311-x86_64-linux-gnu.so` or `.abi3.so`). * Create a cheap `symlink` from the CSL output to the PEP 3149 name. * Propagate `PyInfo` (for python rules) and `CcSharedLibraryInfo` (for dynamic C++ dependencies). * **ODR Validation**: Leveraging native `cc_shared_library` ensures strict analysis-time validation against One Definition Rule (ODR) violations (e.g., duplicate static linkage in dynamic chains). #### 3. Runfiles and Data Support * **Runfiles Propagation**: Re-implemented runfiles collection using the repository's standard `builders.RunfilesBuilder` to support runtime assets (`data` attribute) and dynamic library dependency propagation. ### Verification & Testing * Added parity test cases in `dependency_graph_tests.bzl` to verify dynamic dependency chains and static sharing behavior. * Added runfiles validation in `py_extension_tests.bzl` to verify data asset propagation. * Updated limited API tests to match CSL output structure. * All 14 tests in `//tests/cc/py_extension/...` are compiling and passing. ────── TAG=agy CONV=23f8a5e8-2d99-401a-9903-1256b7d42b0e --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

jsun-splunk and others added 13 commits June 17, 2026 05:03

chore: prepare 2.1 release (bazel-contrib#3829)

5c32fa9

Update changelog and version markers --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

ci: enable bazel-diff (bazel-contrib#3838)

ca86984

Enable bazel-diff to improve CI performance by skipping targets that aren't affected by a PR

rsartor-cmd changed the title ~~Py extension~~ feat: Rule for C extensions Jun 23, 2026

gleyba and others added 7 commits June 24, 2026 03:26

chore: remove accidentally committed release automation plan (bazel-c…

0384676

…ontrib#3846) This file was not intended to be tracked in the repository, so it has been removed.

rsartor-cmd force-pushed the py-extension branch from c050aed to 109eb69 Compare June 26, 2026 18:05

rickeylev and others added 7 commits June 28, 2026 06:56

build(ci): consolidate PR guardrails and block draft files (bazel-con…

9ed7641

…trib#3859) Create a workflow for lighter weight PR checks. These just check basic things about a PR, e.g. markers to prevent submit, blocking files that shouldn't be checked in.

ci: make pr-metadata-check run on PR body edit (bazel-contrib#3862)

20db956

Make the check run on edit so that it can detect adding/removing of the special marker text.

chore(pypi): cleanup unused code (bazel-contrib#3864)

367190a

This is no longer used starting when we enabled pipstar by default and did a code cleanup where Python is no longer used to extract the wheels. Split from bazel-contrib#3856

rsartor-cmd force-pushed the py-extension branch from 815f0fd to 9bfc331 Compare June 29, 2026 18:58

rickeylev and others added 18 commits July 3, 2026 20:28

chore: remove stale process-backports-before-rc news file (bazel-cont…

b5d754e

…rib#3904) This news file was left over from a previous release process and is no longer needed. Removed the file `news/process-backports-before-rc.changed.md`.

chore(release): fix invalid workflow file syntax (bazel-contrib#3908)

89eba16

Quote the 'if' condition in release_create_release_branch.yaml to fix YAML syntax error.

rsartor-cmd force-pushed the py-extension branch 2 times, most recently from acf55b4 to aab3cee Compare July 15, 2026 17:22

rickeylev and others added 9 commits July 17, 2026 22:05

empty impl

03857d3

basic attr builder usage

277ab3a

add stub tests

35ff071

vibe coded py_extension impl. looks roughly valid, but untested

3549106

making more vibe coded progress

8ce90ac

gave up vibe coding. confidence isn't correctness.

97d7811

...and sycophantic toasters are bad collaborators

try cc_shared_library impl

f1fbd96

rsartor-cmd force-pushed the py-extension branch from 0425e9f to 549bc49 Compare July 17, 2026 22:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Rule for C extensions#1

feat: Rule for C extensions#1
rsartor-cmd wants to merge 82 commits into
mainfrom
py-extension

rsartor-cmd commented Jun 23, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

Conversation

rsartor-cmd commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

rsartor-cmd commented Jun 23, 2026 •

edited

Loading