fix(gazelle)!: use per-version stdlib lists for Python 3.13 and 3.14 - #3978
Merged
Conversation
The stdlib list embedded in the gazelle Python extension is selected by python_version, but the select had no branch for 3.13 or 3.14, so those configurations fell through to the 3.11 list. Gazelle is therefore unaware of modules added/removed in Python 3.13/3.14 (eg: `compression.zstd` was added in 3.14, `telnetlib` was removed in 3.13). Bump `python_stdlib_list` to `stdlib-list` `0.12.0`, the first release shipping `lists/3.13.txt` and `lists/3.14.txt`, and add the two matching branches. Update the `//conditions:default` branch to points at the newest available list rather than 3.11, so configurations with no matching branch get a current list instead of one four releases behind. Fetch the archive from the PyPI sdist rather than a GitHub release asset. `0.12.0` published no release assets, so the old URL pattern 404s. GitHub's auto-generated tag archives are not checksum-stable. PyPI permanently reserves a filename once uploaded, and files.pythonhosted.org is already a fetch source for this module.
d818bec fixed the gazelle stdlib list select to have branches for Python 3.13 and 3.14, but shipped no news entry. Per CONTRIBUTING.md, user-visible fixes need one so the change shows up in CHANGELOG.md at release time. Adds news/3978.fixed.md describing the misclassification of modules added/removed since 3.11 and the new default-branch behavior. Omits the internal `stdlib-list` version bump and sdist URL change, which aren't user-visible.
d818bec added `is_python_3.14` as a select() key. Bazel resolves every select() key at analysis time, so that target must exist even when 3.14 is not selected. It first exists in rules_python 1.5.0. Older versions fail analysis: no such target '@@rules_python+//python/config_settings:is_python_3.14' This broke the 9 "Gazelle: BCR" jobs. They drop the local rules_python override, so the example's pin resolved to 1.4.1. Bumps the two pins that were older: the plugin's own bazel_dep (0.18.0) and the example's (1.4.0). The 3-step process in CONTRIBUTING.md does not apply here. A select() key cannot be feature-flagged. This matches how the Gazelle 0.30.0 minimum was raised (see CHANGELOG.md). BREAKING CHANGE: The gazelle plugin now requires rules_python 1.5.0 or higher.
cj81499
changed the title
lpulley
approved these changes
Jul 31, 2026
cj81499
marked this pull request as ready for review
July 31, 2026 18:04
dougthor42
approved these changes
Jul 31, 2026
aignas
approved these changes
Aug 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gazelle Python extension picks its stdlib list by
python_version. The select had no branch for3.13or3.14, so those configurations fell through to the3.11list and gazelle misses everything that changed since3.11(3.14addedcompression.zstd,3.13removedtelnetlib).Bump
python_stdlib_listtostdlib-list0.12.0, the first release shippinglists/3.14.txt, and add the two matching branches. Point//conditions:defaultat the newest list, so configurations with no matching branch stop landing on one four releases behind.Fetch the archive from the PyPI sdist rather than a GitHub release asset. Unlike
0.11.0,0.12.0published no GitHub release assets. GitHub's auto-generated tag archives are not checksum-stable. PyPI never reuses an uploaded filename.BREAKING CHANGE: Gazelle plugin now requires rules_python 1.5.0
Bazel resolves every
select()key at analysis time, sois_python_3.14must exist even for builds that never select it.rules_pythongenerates that target fromMINOR_MAPPING, which lists3.14starting in1.5.0. Older versions fail analysis, and that broke theGazelle: BCRjobs on the first push.Two pins constrain resolution, and both move to
1.5.0: the plugin's ownbazel_dep(was0.18.0) andgazelle/examples/bzlmod_build_file_generation(was1.4.0). The example'sother_modulekeeps its placeholder pin, which the root module overrides.Testing
I added no automated coverage and would appreciate maintainer input on how, if at all, to test this. I didn't see an obvious way given the existing test infra.