Skip to content

feat: enable pyproject.toml as single source of truth for Python version#3514

Open
janwinkler1 wants to merge 5 commits intobazel-contrib:mainfrom
janwinkler1:pyproject-toml-handling
Open

feat: enable pyproject.toml as single source of truth for Python version#3514
janwinkler1 wants to merge 5 commits intobazel-contrib:mainfrom
janwinkler1:pyproject-toml-handling

Conversation

@janwinkler1
Copy link
Contributor

  • Enables using pyproject.toml as single source of truth for Python version via
    python.defaults(pyproject_toml=...) and pip.default(pyproject_toml=...).

  • Creates python_version_from_pyproject repository for BUILD file usage:

load("@python_version_from_pyproject//:version.bzl", "PYTHON_VERSION")
compile_pip_requirements(python_version = PYTHON_VERSION, ...)
  • Makes config_settings optional in pip.default(). Previously, users had
    to pass an empty list (config_settings = []) even when not using platform-specific
    configurations. Now it can be omitted entirely when not needed.

Changes:

  • Added pyproject_toml attribute to python.defaults() and pip.default()
  • Reads Python version from requires-python field (must be ==X.Y.Z format)
  • Made config_settings optional in pip.default() (was mandatory, even for empty lists)
  • Made python_version optional in pip.parse() when using pip.default(pyproject_toml=...)
  • Extracted version parsing to shared Python script for maintainability

Requirements:

  • requires-python = "==X.Y.Z" format in pyproject.toml
  • Python >=3.11 or tomli package on host system

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @janwinkler1, 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 Python ecosystem's integration by introducing pyproject.toml as a primary source for defining Python versions within Bazel projects. It streamlines configuration by allowing python.defaults() and pip.default() to automatically infer the Python version from pyproject.toml, reducing redundancy and potential for discrepancies. Additionally, it improves the developer experience by making config_settings optional in pip.default() and providing a dedicated repository for accessing the pyproject.toml-defined Python version in BUILD files.

Highlights

  • Centralized Python Version Management: Introduced the pyproject_toml attribute to python.defaults() and pip.default(), enabling the Python version to be read directly from pyproject.toml's requires-python field. This establishes pyproject.toml as a single source of truth for Python versions across the project.
  • BUILD File Integration for Python Version: A new repository rule, python_version_from_pyproject, has been created. This rule generates a version.bzl file that exports the PYTHON_VERSION constant, allowing BUILD files to import and use the Python version defined in pyproject.toml without hardcoding it.
  • Simplified pip.default() Configuration: The config_settings attribute in pip.default() is now optional. Previously, users had to pass an empty list (config_settings = []) even when no platform-specific configurations were needed, but now it can be omitted entirely.
  • Flexible pip.parse() Usage: The python_version attribute in pip.parse() is now optional when pip.default(pyproject_toml=...) is used, as the version can be automatically inferred from the pyproject.toml file specified in the defaults.
  • Dedicated Version Extraction Logic: The logic for parsing and extracting the Python version from pyproject.toml has been moved into a shared Python script (pyproject_version_extractor.py), improving maintainability and reusability of the version parsing functionality.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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 significant and valuable feature by enabling pyproject.toml as a single source of truth for Python versions in both python.defaults() and pip.default(). This enhancement greatly improves consistency and maintainability across projects. The implementation includes a new repository rule (pyproject_version_repo) and utility functions to extract and validate the Python version from pyproject.toml. Additionally, config_settings in pip.default() has been made optional, which is a good usability improvement. The changes are well-tested with dedicated integration and priority tests, ensuring the new functionality works as expected and respects the defined priority order for Python version resolution. The code is clean, well-documented, and adheres to best practices.

@janwinkler1 janwinkler1 marked this pull request as draft January 15, 2026 07:05
@janwinkler1 janwinkler1 force-pushed the pyproject-toml-handling branch 2 times, most recently from 958106b to 1a1fef2 Compare January 15, 2026 07:46
@janwinkler1 janwinkler1 marked this pull request as ready for review January 15, 2026 07:57
@janwinkler1 janwinkler1 force-pushed the pyproject-toml-handling branch from 1a1fef2 to bd73882 Compare January 15, 2026 08:07
@aignas
Copy link
Collaborator

aignas commented Jan 19, 2026

Hey, thank you for the contribution.

In general I am +1 on having the python version read from pyproject.toml but I have concerns on depending on Python for doing that. It is trivial to do it in Python but we have a layering violation, because we need to use some python interpreter before the interpreters are setup and that would mean that we would have to use the Python interpreter from the system.

  • Creates python_version_from_pyproject repository for BUILD file usage:
load("@python_version_from_pyproject//:version.bzl", "PYTHON_VERSION")
compile_pip_requirements(python_version = PYTHON_VERSION, ...)

What is the benefit of this? If we are setting the default version through the pyproject.toml interpreter, the python_version should not need to be set anymore in this way.

  • Makes config_settings optional in pip.default(). Previously, users had
    to pass an empty list (config_settings = []) even when not using platform-specific
    configurations. Now it can be omitted entirely when not needed.

+1 on this change. If you'd like to merge it earlier than we decide on the various pyproject.toml processing specific details, please submit a separate PR.

  • Added pyproject_toml attribute to python.defaults() and pip.default()

LGTM, but I am wondering if this is the simplest possible interface. We could instead reuse, continue using the machinery that is used by .python-version and do detection based on extension. If it is called a pyproject.toml, then we know for sure what it can contain.

  • Reads Python version from requires-python field (must be ==X.Y.Z format)

Do we need to restrict the user to ==X.Y.Z? Should we also support X.Y? What about >=X.Y? We do have python version parsing reimplemented in Starlark, so we process this information statically.

  • Made python_version optional in pip.parse() when using pip.default(pyproject_toml=...)

Is the idea to set the default value for //python/config_settings:python_version from pyproject.toml? If so, should we do this change in 2 steps - make the pip.parse python_version optional and fallback to the default version?

@rickeylev
Copy link
Collaborator

I, too, am supportive of this.

layering violation, using python to parse it

I'm not worried about that. We should just pick a python runtime to use for repo-phase logic that rules_python uses. It simplifies us being able to assume what python is being used and its capabilities. There's also the config bzlmod extension we could use to give some ability to customize what python we use during the repo phase.

what syntax of requires-python should we support, how do they work

I'd say lets just go with what the author is willing to contribute. If someone later wants >, then they can send a PR.

@janwinkler1
Copy link
Contributor Author

hi @aignas and @rickeylev, thank you for your comments! i am currently taking a vacation, will address your comments nexy week! cheerio

Copy link
Collaborator

@rickeylev rickeylev left a comment

Choose a reason for hiding this comment

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

Core logic is OK, but some of the impl details and tests need to change

continue

for tag in mod.tags.default:
pyproject_toml = getattr(tag, "pyproject_toml", None)
Copy link
Collaborator

Choose a reason for hiding this comment

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

The pyproject tag will always be present, so this can use normal . for accessing.

),
"config_settings": attr.label_list(
mandatory = True,
mandatory = False,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think a recent PR fixed this?

),
"pyproject_toml": attr.label(
mandatory = False,
allow_single_file = True,
Copy link
Collaborator

Choose a reason for hiding this comment

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

allow_single_file can be omitted. It has no meaning for repo/bzlmod rules

The version must be specified as `==X.Y.Z` (exact version with full semver).
This is designed to work with dependency management tools like Renovate.

:::{versionadded} 1.8.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Change to VERSION_NEXT_FEATURE instead of 1.8.0

),
"python_version": attr.string(
mandatory = True,
mandatory = False,
Copy link
Collaborator

Choose a reason for hiding this comment

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

update python_version attr doc to indicate the other option

add e.g.

:::{seealso}
The {obj}`pyproject_toml` attribute for getting the version from a project file.
:::

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, this is a good opportunity to add a toml2json tool, there's another pending PR that needs it, too.

Copy the toml2json tool from https://github.com/bazel-contrib/rules_python/pull/3557/changes and use it in this PR for parsing the pyproject.toml file.

  • Copy tools/toml2json; move it to tools/private/toml2json
  • Copy its tests.
  • Use convert_uv_lock_to_json in python/private/pypi/uv_lock.bzl as inspiration for creating a pyproject_to_json bzl function. Notably, invoke the helper toml2json script using the utility functions it uses. These ensure the script is executed correctly/safely.

)
if default_python_version_file:

# Priority order: pyproject_toml > python_version_file > python_version_env > python_version
Copy link
Collaborator

Choose a reason for hiding this comment

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

This logic needs to be partially reverted, as its changing behavior.

The ENV attribute has highest precedence (this allows overriding on the command line), followed by version file. I'm not sure if .python-version or pyproject.toml should have higher precedence; I'm think pyproject.toml should be higher, though.

Comment on lines +968 to +969
# Check if pyproject_toml was specified in defaults
# If so, register a toolchain for it
Copy link
Collaborator

Choose a reason for hiding this comment

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

The diff is hiding a lot of the content -- is this new logic specific to pyproject? It would make sense that this occurs for whatever default is used, not just if pyproject is.

When specified, reads the `requires-python` field from pyproject.toml.
The version must be specified as `==X.Y.Z` (exact version with full semver).

:::{versionadded} 1.8.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Specify VERSION_NEXT_FEATURE

Copy link
Collaborator

Choose a reason for hiding this comment

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

These tests are OK, but they're integration tests. We only add integration tests when absolutely necessary because we have a limited number of jobs we can run (and we're near that limit already).

I think there are some more unittest-style things with pieces mocked out.

Otherwise, we'll just have to leave the code paths as untested 🤷

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.

3 participants