[py] pin python versions to specific patches

[titusfortner]

User description

I noted that there are a bunch of slightly different python toolchain caches generated that may come from different patch versions, so this ensures everything is pinned to the same thing.

💥 What does this PR do?

• Update to rules_python 1.7 (this is required for Bazel 8 anyway - [bazel] Update to Bazel 8 #16757)
• Pin specific patch versions of Python
• Ensures our scripts use bazel python

---

PR Type

Enhancement

---

Description

• Upgrade rules_python from 1.6.3 to 1.7.0

• Pin Python toolchain versions to specific patch releases

• Ensure consistent Python environment across all build configurations

• Add missing py_binary import to scripts BUILD file

---

Diagram Walkthrough

flowchart LR
  A["rules_python 1.6.3"] -- "upgrade to" --> B["rules_python 1.7.0"]
  C["Python versions<br/>3.10, 3.11, 3.12, 3.13, 3.14"] -- "pin to patch versions" --> D["3.10.19, 3.11.14, 3.12.12, 3.13.9, 3.14.0"]
  B --> E["Consistent toolchain<br/>configuration"]
  D --> E

Loading

File Walkthrough

	Relevant files
Configuration changes	MODULE.bazel Upgrade rules_python and pin Python patch versions              MODULE.bazel Upgrade rules_python dependency from version 1.6.3 to 1.7.0 Pin Python toolchain versions to specific patch releases (3.10.19, 3.11.14, 3.12.12, 3.13.9, 3.14.0) Update pip.parse extension to use pinned patch versions for all Python versions +11/-11
Bug fix	BUILD.bazel Add py_binary import to scripts BUILD file                              scripts/BUILD.bazel Add missing import for py_binary from @rules_python//python:defs.bzl +1/-0

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use valid, existing Python versions Replace the invalid Python patch versions with the latest available official releases (e.g., 3.10.14, 3.11.9, 3.12.4) to prevent build failures. Consider removing unreleased versions like 3.13 and 3.14. MODULE.bazel [126-151] python.toolchain( is_default = True, - python_version = "3.10.19", + python_version = "3.10.14", ) -python.toolchain(python_version = "3.11.14") -python.toolchain(python_version = "3.12.12") -python.toolchain(python_version = "3.13.9") -python.toolchain(python_version = "3.14.0") +python.toolchain(python_version = "3.11.9") +python.toolchain(python_version = "3.12.4") +# Python 3.13 and 3.14 are not yet stable. +# Consider adding them back once a stable .0 release is available. +# python.toolchain(python_version = "3.13.1") +# python.toolchain(python_version = "3.14.0") use_repo(python, "pythons_hub") pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip") [ pip.parse( hub_name = "py_dev_requirements", python_version = version, requirements_lock = "//py:requirements_lock.txt", ) for version in [ - "3.10.19", - "3.11.14", - "3.12.12", - "3.13.9", - "3.14.0", + "3.10.14", + "3.11.9", + "3.12.4", ] ] Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies that the specified Python patch versions are invalid and do not exist, which would cause the build to fail. This is a critical issue in the PR.	High
Learned best practice	Centralize repeated pinned versions Define the pinned Python versions once (e.g., PYTHON_VERSIONS) and reuse it for both toolchain registration and pip.parse to avoid inconsistencies when versions change. MODULE.bazel [126-151] +PYTHON_VERSIONS = [ + "3.10.19", + "3.11.14", + "3.12.12", + "3.13.9", + "3.14.0", +] + python.toolchain( is_default = True, - python_version = "3.10.19", + python_version = PYTHON_VERSIONS[0], ) -python.toolchain(python_version = "3.11.14") -python.toolchain(python_version = "3.12.12") -python.toolchain(python_version = "3.13.9") -python.toolchain(python_version = "3.14.0") +[ + python.toolchain(python_version = version) + for version in PYTHON_VERSIONS[1:] +] use_repo(python, "pythons_hub") pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip") [ pip.parse( hub_name = "py_dev_requirements", python_version = version, requirements_lock = "//py:requirements_lock.txt", ) - for version in [ - "3.10.19", - "3.11.14", - "3.12.12", - "3.13.9", - "3.14.0", - ] + for version in PYTHON_VERSIONS ] Apply / Chat Suggestion importance[1-10]: 6 __ Why: Relevant best practice - Replace ad-hoc duplication with shared helpers/utilities (centralize repeated values like pinned version lists) to reduce repetition and prevent drift.	Low
More

[cgoldberg]

I guess this is fine if it helps with cache, but I like the idea of just using the latest patch release for each version. With this, we will constantly have to bump the versions as new releases come out if we want to use them.

[titusfortner]

Kind of the point that it shouldn't change versions without you knowing. Ideally dependabot or whatever would know to look at python rules in module. 😂

[titusfortner]

Also it's nice that this PR shows where we aren't referencing python with bazel properly