[py] Bump python dev dependencies

[cgoldberg]

💥 What does this PR do?

This PR bumps Python development dependenciesto the latest versions

• update package versions in requirements.txt
• generate new lock file
• update multitool binaries
• update pyproject.toml

🔄 Types of changes

• Dev/CI

[qodo-code-review]

Review Summary by Qodo

Bump Python development dependencies to latest versions

✨ Enhancement

Walkthroughs

Description

• Update ruff from 0.15.6 to 0.15.8
• Bump multiple Python dependencies to latest versions
• Update lock file with new package hashes
• Refresh multitool binaries for ruff

File Changes

1. py/pyproject.toml Dependencies +1/-1

Update ruff version in pyproject.toml

• Update ruff dependency from 0.15.6 to 0.15.8 in lint group

py/pyproject.toml

---

2. py/requirements.txt Dependencies +9/-9

Bump multiple Python package versions

• Update chardet from 7.2.0 to 7.4.0.post2
• Update cryptography from 46.0.5 to 46.0.6
• Update importlib_metadata from 8.8.0 to 9.0.0
• Update jaraco.context from 6.1.1 to 6.1.2
• Update nh3 from 0.3.3 to 0.3.4
• Update Pygments from 2.19.2 to 2.20.0
• Update requests from 2.32.5 to 2.33.0
• Update tomli from 2.4.0 to 2.4.1
• Update tox from 4.50.1 to 4.51.0

py/requirements.txt

---

3. py/requirements_lock.txt Dependencies +180/-173

Regenerate lock file with updated dependency hashes

• Update chardet hashes for version 7.4.0.post2
• Update cryptography hashes for version 46.0.6
• Update importlib-metadata hashes for version 9.0.0
• Update jaraco-context hashes for version 6.1.2
• Update nh3 hashes for version 0.3.4
• Update pygments hashes for version 2.20.0
• Update requests hashes for version 2.33.0
• Update tomli hashes for version 2.4.1
• Update tox hashes for version 4.51.0
• Update python-discovery from 1.2.0 to 1.2.1

py/requirements_lock.txt

---

View more (1)

4. multitool.lock.json ⚙️ Configuration changes +10/-10

Update ruff multitool binaries to 0.15.8

• Update ruff binaries from 0.15.6 to 0.15.8 for all platforms
• Update SHA256 hashes for Linux ARM64, Linux x86_64, macOS ARM64, macOS x86_64, and Windows x86_64
 binaries

multitool.lock.json

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Deps updater skips packages 🐞 Bug ⚙ Maintainability

Description

The standard dependency bump task (rake python:pin) runs scripts/update_py_deps.py, but that
script looks up installed packages using non-canonical names (underscores/dots preserved) while `pip
list` reports canonical distribution names (hyphens). As a result, packages like
importlib_metadata, mypy_extensions, and readme_renderer in py/requirements.txt can be
silently skipped by the updater, leading to incomplete future bumps.

Code

py/requirements.txt[19]

+importlib_metadata==9.0.0

Evidence

rake python:pin invokes //scripts:update_py_deps, so this updater is part of the supported
workflow. The updater only lowercases/strips extras when building the lookup key, but
py/requirements_lock.txt shows the canonical (hyphenated) distribution names that pip list
typically returns; this mismatch means installed.get(name_normalized) can return None and the
line will not be updated.

rake_tasks/python.rake[132-138]
scripts/update_py_deps.py[22-32]
scripts/update_py_deps.py[71-85]
py/requirements.txt[19-33]
py/requirements_lock.txt[424-430]
py/requirements_lock.txt[848-854]
py/requirements_lock.txt[985-992]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`scripts/update_py_deps.py` builds an `installed` map from `pip list --format=json` and then looks up versions using a key derived from the requirement line. The script only lowercases and strips extras, so requirement names containing `_`/`.` may not match pip’s canonical distribution names (which normalize `[-_.]+` to `-`). This can cause the updater to skip some packages without error.

### Issue Context
The supported workflow (`rake python:pin`) runs this script before regenerating `py/requirements_lock.txt`, so silent skips can leave `py/requirements.txt` partially stale.

### Fix Focus Areas
- scripts/update_py_deps.py[22-32]
- scripts/update_py_deps.py[71-85]

### Implementation notes
- Use `packaging.utils.canonicalize_name()` (preferred) or apply PEP 503 normalization (`re.sub(r"[-_.]+", "-", name).lower()`) to both:
 - the requirement-derived key (`name_normalized`)
 - the `installed` dict keys (or normalize on lookup)
- Add a small unit-style assertion/logging: if `new_version is None`, emit a warning listing the unmatched package name.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Lockfile reused across Pythons 🐞 Bug ⛯ Reliability

Description

py/requirements_lock.txt is compiled with Python 3.10, but Bazel consumes that same lockfile for
multiple toolchains (3.10 through 3.14). After dependency bumps, any package that isn’t compatible
with a newer toolchain can break Bazel dependency resolution even if it works on 3.10.

Code

py/requirements_lock.txt[R1141-1143]

+tox==4.51.0 \
+    --hash=sha256:df848c4d9864ec6333c6e2b427fdc182b9f1d840d2bed072997bd48104269182 \
+    --hash=sha256:e3967c0c2d7318d0b14a38d8cbb6ec2d12008574d612c1774fd00d376c7d5e6a

Evidence

The lockfile header states it was generated with Python 3.10. MODULE.bazel then calls
pip.parse(... requirements_lock = "//py:requirements_lock.txt") in a loop for multiple
python_version values (3.10.19, 3.11.14, 3.12.12, 3.13.11, 3.14.2), meaning one lockfile is
expected to work across all those interpreters.

py/requirements_lock.txt[1-6]
MODULE.bazel[125-151]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A single `py/requirements_lock.txt` generated under Python 3.10 is used by Bazel `pip.parse` for Python 3.10–3.14 toolchains. Dependency bumps can introduce packages that are not installable/compatible for one of the newer toolchains, causing Bazel resolution failures.

### Issue Context
This PR updates multiple pinned versions in `py/requirements_lock.txt`, increasing the chance that at least one transitive dependency has tighter `Requires-Python` or missing distributions for newer interpreters.

### Fix Focus Areas
- py/requirements_lock.txt[1-6]
- MODULE.bazel[138-151]

### Implementation notes
Pick one:
1) Generate separate lockfiles per Python version (e.g., `requirements_lock_py310.txt`, `..._py311.txt`, etc.) and point each `pip.parse(python_version=..., requirements_lock=...)` to the matching lock.
2) If you intend a single lock, adjust the lock generation process to explicitly account for the full supported Python range (e.g., generate with markers / multi-version constraints) and document that in the lock header and update scripts.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[cgoldberg]

RBE failures are unrelated.. all python tests pass