Skip to content

Conversation

@rickeylev
Copy link
Collaborator

@rickeylev rickeylev commented Sep 7, 2025

This implements the ability for users to add additional settings that py_binary, py_test,
and py_wheel can transition on.

There were three main use cases motivating this feature:

  1. Making it easier to have multiple pypi dependency closures and shared dependencies.
  2. Making it easier to override flags for py_wheel.
  3. Making it easier to have per-target setting of things like bootstrap_impl, venv
    site packages, etc.

It also adds most of our config settings to the the transition inputs/outputs for those
rules, which allows users to per-target force particular settings without having to
use e.g. with_cfg to wrap a target with the desired transition settings. It also
lets use avoid adding dozens of attributes (one per setting); today there are
about 17 flags.

Under the hood, this works by having a bzlmod api that users can pass labels to. These
labels are put into a generated bzl file, which the rules load and add to their
list of transition inputs/outputs. On the target level, the config_settings attribute,
which is a dict[label, str], can be set to change the particular flags of interest.

Along the way...

  • Create a common_labels.bzl file for the shared label strings
  • Remove the defunct py_reconfig code in sh_py_run_test.

@rickeylev rickeylev requested a review from aignas as a code owner September 7, 2025 23:18
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @rickeylev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the configuration capabilities of rules_python by allowing py_binary, py_test, and py_wheel rules to apply arbitrary build settings on a per-target basis. This feature addresses common use cases such as managing multiple PyPI dependency closures, overriding flags for py_wheel builds, and setting specific configurations like bootstrap_impl or venv site packages for individual targets. The changes involve a new module extension for registering custom settings, a new attribute on the rules themselves, and internal refactoring to support this flexible configuration mechanism.

Highlights

  • Arbitrary Setting Transitions: Introduces the ability for py_binary, py_test, and py_wheel rules to transition on arbitrary build settings, enabling more flexible configuration per target.
  • New config_settings Attribute: Adds a config_settings attribute to executable Python rules, allowing users to specify custom flag values for individual targets without needing to wrap them in with_cfg.
  • Module Extension for Custom Settings: Implements a new rules_python_config module extension with an add_transition_setting tag, providing a bzlmod API for users to register their own custom settings for transitions.
  • Enhanced Default Transitions: Most existing rules_python configuration settings are now automatically included in the default transition inputs and outputs for py_binary, py_test, and py_wheel.
  • Multi-PyPI Dependency Management Guide: Adds new documentation demonstrating how to manage common dependencies across multiple PyPI versions using the new config_settings feature and custom flags.
  • Code Refactoring and Cleanup: Refactors and removes defunct py_reconfig code from sh_py_run_test.bzl, consolidating it into a dedicated py_reconfig.bzl file for better organization.
  • Standardized Label Handling: Introduces new utility functions and files (common_labels.bzl, transition_labels.bzl) to standardize and normalize the handling of build setting labels used in transitions.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a powerful feature allowing users to register arbitrary settings for py_binary, py_test, and py_wheel to transition on. This is a significant improvement for managing complex dependency graphs, especially in monorepos with multiple PyPI dependency sets. The implementation is well-structured, introducing a new bzlmod extension, a repository rule to generate configuration, and refactoring existing rules to use this new mechanism. The addition of tests and documentation is also commendable. My feedback is mostly focused on minor corrections in the documentation to ensure clarity for users.

@rickeylev
Copy link
Collaborator Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a powerful feature allowing users to register arbitrary settings for py_binary, py_test, and py_wheel transitions. The implementation is well-structured, introducing a new bzlmod extension //python/extensions:config.bzl and a config_settings attribute on the relevant rules. The changes are accompanied by thorough tests and new documentation, which is excellent.

My review focuses on a few minor documentation and docstring improvements to enhance clarity and correctness. Overall, this is a solid contribution that addresses several important use cases for rules_python users.

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Copy link
Collaborator

@aignas aignas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general.

@rickeylev rickeylev added this pull request to the merge queue Sep 9, 2025
Merged via the queue into bazel-contrib:main with commit 37cb91a Sep 9, 2025
4 checks passed
@rickeylev rickeylev deleted the pypi.flag branch September 9, 2025 04:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants