It drops support for Python3.9, it add support for Python 3.13, and it drops nox dependencies in favor of uv.

[fressi-elastic]

In October 2025 Python.org is planning the release of Python 3.14 and dropping support for Python 3.9. This PR is following the trend dropping version 3.9 and adding the support of the now 1 year old Python 3.13.

It also remove testing Python 3.9 support in the make test goal. It instead provide goals to run tests with specific python versions (test-3.10, test-3.11, test-3.12 and test-3.13, one for each supported version).
'make test' is now equivalent to 'make test-3.12`.

The main idea is developers will test changes with their most convenient Python version, while the whole range of supported python versions should be better tested at continuous integration stage.

[gareth-ellis]

Can we update readme too? You mention that 3.12 is the preferred version, we should perhaps call that out in the readme too?

https://github.com/elastic/rally/blob/master/README.md?plain=1#L27

And also docs:
https://github.com/elastic/rally/blob/master/docs/install.rst?plain=1#L21

It may be worth grepping for 3.9, see if there's other occurances too

[fressi-elastic]

Can we update readme too? You mention that 3.12 is the preferred version, we should perhaps call that out in the readme too?

https://github.com/elastic/rally/blob/master/README.md?plain=1#L27

And also docs: https://github.com/elastic/rally/blob/master/docs/install.rst?plain=1#L21

It may be worth grepping for 3.9, see if there's other occurances too

True!

[fressi-elastic]

@gareth-ellis @gbanasiak Can you please give it another look? Cheers.

[gbanasiak]

I think it would make sense to bump DEFAULT_PY_VER to 3.13 in this PR moving development environment to 3.13. If not now then when? Please also update Python versions in mypy and black configuration in pyproject.toml.

[fressi-elastic]

Ok!

[gbanasiak]

Python upgrade PR turned into Python upgrade + Makefile refactor + nox replacement (although not complete as noxfile.py is still there). The title does not reflect the content. I suggest to reduce the scope to the original one in order to achieve the initial goal of enabling 3.13 while removing 3.9, and move nox removal to another PR. I don't feel sentimental about nox, if uv is faster let's do it.

[fressi-elastic]

@gareth-ellis @gbanasiak Can you please give another look at this change? I hope I didn't forget nothing. Cheers

[gareth-ellis]

LGTM

[gbanasiak]

-s in nox has different meaning than in make, is this intentional?

[fressi-elastic]

It is not intentional! It's a mistake.

[gbanasiak]

Any particular reason for reintroducing pip with --seed? Isn't the 2nd command enough?

[fressi-elastic]

I guess I copied from somewhere. I must check what happen removing there options. Also the --allow-existing should not be necessary anymore.

[gbanasiak]

Previously install was unconditional which allowed going back and forth with the venv state when PR updates dependencies. Now once venv is installed, the only way to update dependencies is running reinstall. Is this intentional?

[fressi-elastic]

For venv I wanted to give a behavior similar to what I would expect from a regular Makefile when creating something. It may be I should restore the old behaviour for make install. Thank for reporting.

[gbanasiak]

We had alignment between Rally and esbench on that one. Now we don't. I don't mind changing my habits from make install to make reinstall (although make install was communicated earlier to people using the latest snapshot as a proper way to update dependencies, which is now broken), but let's keep the same across all related projects.

[fressi-elastic]

I need to create a follow up PR after some comments from @gbanasiak that I didn't handled in time before auto-merge happened.

[pquentin]

Two comments here:

• You didn't replace nox with uv, but with make, which is where the logic to test different Python versions exists. For the record, Nox supports uv with @nox.session(venv_backend="uv"), a CLI parameter or even an environment variable.
• That said, if uv makes it easy to provide Python and install Rally now on Linux and macOS, maybe it's time to force a specific version and not deal with the overhead of supporting older versions.

[gbanasiak]

@pquentin Many thanks for comments.

You didn't replace nox with uv, but with make, which is where the logic to test different Python versions exists.

Indeed.

That said, if uv makes it easy to provide Python and install Rally now on Linux and macOS, maybe it's time to force a specific version and not deal with the overhead of supporting older versions.

uv definitely makes it easy for dev purposes, but how to ship Rally to end-users? Should we stop releasing PyPI packages and provide an installation script which uses uv and git or Docker under the hood? curl -fsSL https://elastic.co/esrally | sh ?

[pquentin]

I don't have answers here, only questions! This is especially true as I'm not working on a Python application these days, so I'm not following the space closely. What I know is that a number of things that were true in 2022 when I created #1420 don't hold true anymore, as you can see in my latest comment there.

uv definitely makes it easy for dev purposes, but how to ship Rally to end-users? Should we stop releasing PyPI packages and provide an installation script which uses uv and git or Docker under the hood? curl -fsSL https://elastic.co/esrally | sh ?

astral-sh/uv#5802 links to https://ofek.dev/pyapp/latest/, which looks promising for the offline install. If that works, then removing mentions of pyenv in favor of uv in the documentation could mean that using the Python version that Rally needs is as easy as uv tool install --python 3.13 esrally==2.12.0

[fressi-elastic]

On my opinion shipping software using a Docker image helps in focusing only on supporting Linux and one recent version of python and forgetting a big platform matrix. Because as a developer this doesn't give a smooth experience with debugger we should also support a recent enough version of Python for both Linux and OSX using a virtual environment. I started this PR because I am seeing issues with thespian, fork, selectors, OSX and python < 3.12. So UV is very helpful because it helps in this context to switch our developer platforms to python 3.12-13, which are the ones we should also use in production. Told that we are still missing an easy way of testing Linux/Docker support from an OSX laptop. I am planning to add something in the Makefile so that we could use it either locally and in CI. This could help dropping more versions of Python and narrow our focus on what matters more.
Thank you for your suggestion!

[fressi-elastic]

I don't have answers here, only questions! This is especially true as I'm not working on a Python application these days, so I'm not following the space closely. What I know is that a number of things that were true in 2022 when I created #1420 don't hold true anymore, as you can see in my latest comment there.

uv definitely makes it easy for dev purposes, but how to ship Rally to end-users? Should we stop releasing PyPI packages and provide an installation script which uses uv and git or Docker under the hood? curl -fsSL https://elastic.co/esrally | sh ?

astral-sh/uv#5802 links to https://ofek.dev/pyapp/latest/, which looks promising for the offline install. If that works, then removing mentions of pyenv in favor of uv in the documentation could mean that using the Python version that Rally needs is as easy as uv tool install --python 3.13 esrally==2.12.0

I guess uvx could be used to run esrally in its own temporary venv: https://docs.astral.sh/uv/guides/tools/