Skip to content

Add 3.14 to CI builds #3103

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
+24 −8
Draft

Add 3.14 to CI builds #3103

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b4a01f7
Add 3.14 to CI builds
miguelgrinberg Oct 13, 2025
5e232b6
Support Python 3.14 __annotate_func__
miguelgrinberg Oct 13, 2025
18ecf95
Temporarily remove pyarrow
miguelgrinberg Oct 13, 2025
8bf3d3a
Update pyproject.toml
miguelgrinberg Oct 14, 2025
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .buildkite/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
ARG PYTHON_VERSION=3.13
ARG PYTHON_VERSION=3.14
FROM python:${PYTHON_VERSION}

# Default UID/GID to 1000
Expand Down
5 changes: 3 additions & 2 deletions .buildkite/pipeline.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,18 +16,19 @@ steps:
- "3.11"
- "3.12"
- "3.13"
- "3.14"
connection:
- "urllib3"
- "requests"
nox_session:
- "test"
adjustments:
- with:
python: "3.9"
python: "3.10"
Comment on lines -26 to +27
Copy link
Member

Choose a reason for hiding this comment

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

Should we require 3.10 here then?

elasticsearch-py/pyproject.toml

Line 10 in a11aab5

requires-python = ">=3.9"
(My preference is to either support 3.9 or not, but you could convince me that keeping it a gray area like you usually do is a good idea.)
Copy link
Contributor Author

@miguelgrinberg miguelgrinberg Oct 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I have no problem dropping 3.9. I didn't want to remove it in this PR though, because I assume we are going to backport this PR to 9.2, 9.1 and 8.19, which do need the 3.14 support, whereas dropping 3.9 only applies to the upcoming 9.2, since I suppose we don't want to also drop it in 9.1 and 8.19 patch releases.
Copy link
Contributor Author

@miguelgrinberg miguelgrinberg Oct 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Also what you call the "gray area" to me means being nice to people by allowing the "requires-python" setting to lag a few releases. To me dropping support of a Python version and preventing people from installing on that version are different things.

So I'm 100% in agreement to drop 3.9. But I don't think it is necessary to bump this setting (which imho should still be 3.8), and I also don't feel necessary to run pyupgrade.
Copy link
Member

Choose a reason for hiding this comment

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

To me dropping support of a Python version and preventing people from installing on that version are different things.

I don't get this part. All popular Python libraries I know (Django, Flask, FastAPI, urllib3, all scientific libraries that endorse SPEC-0, etc.) don't do this. They either support or don't support a given Python version. When they don't support it, they use requires-python to clearly signal it. Well, even microdot, which currently supports Python 3.8+ and still tests it in CI.
Copy link
Contributor Author

@miguelgrinberg miguelgrinberg Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Yes, for all my open source projects I'm at 3.8 right now. At some point I pyupgraded my code to 3.8, so I marked it as invalid for older releases, because it would obviously not work on them. This was not a decision related to what versions I support, but about what the version my Python code is at. Before settling on 3.8 I used 3.6 as baseline for my projects. All I'm planning to do now is to add 3.14 and drop 3.8 from the CI.

I do not feel it makes sense to prevent people from installing on 3.9, which went out of maintenance just days ago. I could be convinced to do this for the upcoming 9.2, but for patch releases on the older 9s and 8.19 it would be weird to do it.
Copy link
Member

Choose a reason for hiding this comment

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

I'm happy to keep Python 3.9 support for Elasticsearch 8.19 and older 9s. However, I suggest dropping Python 3.9 on elasticsearch-py 8.19 in one year, when Python 3.15 gets released. (We kept Python 2.7 forever on elasticsearch-py 7.17, and this was painful, especially as Github Actions and libraries we depend on stopped working and we no longer had CI.)

Feel free to decide about elasticsearch-py 9.2. But if we drop 3.9 in CI, I'll be very tempted to start using pattern matching, parenthesized context managers, and X|Y types. Without necessarily realizing it.
Copy link
Contributor Author

@miguelgrinberg miguelgrinberg Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Okay, so this is what I propose:

  • This PR will add 3.14 and will not remove 3.9. We'll back port it to 9.2, 9.1 and 8.19. We'll then release patches for 9.1 and 8.19 with 3.14 support.
  • We'll add a separate PR that drops 3.9 for the upcoming 9.2 only. I feel a lot less strongly about keeping python-requires at 3.9 on a release that does not exist yet, so for this one release I'm fine bumping it to 3.10. I wouldn't pyupgrade the code immediately because I expect we will continue to back port things from time to time. Once the back port efforts slow down, we can run pyupgrade as well.
Copy link
Member

Choose a reason for hiding this comment

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

Thanks! LGTM.
connection: "urllib3"
nox_session: "test_otel"
- with:
python: "3.13"
python: "3.14"
connection: "urllib3"
nox_session: "test_otel"
command: ./.buildkite/run-tests
2 changes: 1 addition & 1 deletion .buildkite/run-tests
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
# Default environment variables
export STACK_VERSION="${STACK_VERSION:=8.0.0-SNAPSHOT}"
export TEST_SUITE="${TEST_SUITE:=platinum}"
export PYTHON_VERSION="${PYTHON_VERSION:=3.13}"
export PYTHON_VERSION="${PYTHON_VERSION:=3.14}"
export PYTHON_CONNECTION_CLASS="${PYTHON_CONNECTION_CLASS:=urllib3}"

script_path=$(dirname $(realpath $0))
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ jobs:
strategy:
fail-fast: false
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13", "3.14"]
nox-session: [""]
runs-on: ["ubuntu-latest"]

Expand Down
15 changes: 15 additions & 0 deletions elasticsearch/dsl/document_base.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -332,6 +332,21 @@ def __init__(self, name: str, bases: Tuple[type, ...], attrs: Dict[str, Any]):
# # ignore attributes
# field10: ClassVar[string] = "a regular class variable"
annotations = attrs.get("__annotations__", {})
if not annotations:
# Python 3.14+ uses annotationlib
try:
import annotationlib

annotate = annotationlib.get_annotate_from_class_namespace(attrs)
if annotate:
annotations = (
annotationlib.call_annotate_function(
annotate, format=annotationlib.Format.VALUE
)
or {}
)
except ImportError:
pass
fields = {n for n in attrs if isinstance(attrs[n], Field)}
fields.update(annotations.keys())
field_defaults = {}
Expand Down
4 changes: 2 additions & 2 deletions noxfile.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,14 +44,14 @@ def pytest_argv():
]


@nox.session(python=["3.9", "3.10", "3.11", "3.12", "3.13"])
@nox.session(python=["3.9", "3.10", "3.11", "3.12", "3.13", "3.14"])
def test(session):
session.install("-e", ".[dev]", env=INSTALL_ENV, silent=False)

session.run(*pytest_argv(), *session.posargs)


@nox.session(python=["3.9", "3.13"])
@nox.session(python=["3.10", "3.14"])
def test_otel(session):
session.install(
".[dev]",
Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ dev = [
"orjson",
"numpy",
"simsimd",
"pyarrow",
"pyarrow; python_version<'3.14'",
"pandas",
"mapbox-vector-tile",
"jinja2",
Expand Down