feat(toolchain): drop 3.8 and print warnings for its usage #3387
Conversation
Summary of ChangesHello @aignas, 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 experimentally removes support for Python 3.8 by updating the version definitions. The primary goal is to assess what components or tests might break as a result of dropping this specific minor version, in preparation for potential future deprecation. This change impacts the available Python versions for builds and ensures that the system no longer references Python 3.8. Highlights
Using Gemini Code AssistThe 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
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request begins the process of dropping Python 3.8 support by removing its definitions from python/versions.bzl. The changes correctly remove the 3.8.20 version from TOOL_VERSIONS and the 3.8 mapping from MINOR_MAPPING. These changes are correct and align with the PR's goal.
As this is an experiment to see what breaks, other areas to investigate will be CI configurations for Python 3.8 and any remaining 3.8-specific files. I also noticed an example in a comment in python/versions.bzl (lines 40-51) that still uses Python 3.8.10; updating this to a supported version would be a good follow-up to avoid confusion.
|
hmmm, it looks like the situation is the same, I guess we need to start bumping the |
|
Coffee thoughts:
|
aignas
force-pushed
the
chore/drop-3.8
branch
from
3e8010a to
9b4a71a
Compare
aignas
changed the title
|
|
||
| self._platforms[python_version] = _platforms( | ||
| python_version = python_version, | ||
| full_python_version = full_version( |
There was a problem hiding this comment.
TODO: unit test this.
| parts = version.split(".") | ||
| if len(parts) == 3: | ||
| return version | ||
| elif not err: |
|
|
||
| # TODO @aignas 2025-11-04: use env-marker-setting with the smallest minor_mapping version | ||
| native.alias( | ||
| name = "is_python_{}".format(minor), |
There was a problem hiding this comment.
We need targets that are for other Python versions, but maybe instead of this hack to make the versions incompatible, we colud do it differently:
for minor in range("3.0", max(minor_mapping)):
native.config_setting()
That way we'll get the right behaviour. Another option would be to leave minor_mapping[3.8] = None. That way we might get the right behaviour as well.
1 participant
Drop 3.8 and print warnings whenever it is used. Maybe we should
demote it to
DEBUGorINFOinstead?In order to ensure that
is_python_3.xflags continue working, wejust alias them to
@platforms//:incompatible. I think maybe we shoulduse a
env_marker_settingflag instead?Work towards #2704