Consider matching the Python version used by ehrQL rather than by `python:v2`

[evansd]

As things stand at the time of writing, this means installing Python 3.13 rather than 3.10:

research-template-docker/Dockerfile

Lines 26 to 28 in a1caf69

	# Install python 3.10. This is the version used by the python-docker
	# image, used for analyses using the OpenSAFELY pipeline.
	--no-install-recommends curl python3.10 python3.10-distutils python3.10-venv \

Given that different images use different versions of Python (ehrql, python:v1, python:v2, python:v3 when it comes etc.) there's no single, obviously correct version to install. But I think it makes sense to prioritise matching the version used by ehrQL for a few reasons:

1. The main impact of the installed version is to change the error checking and autocomplete behaviour of VS Code. Actually running the code should always be handled by the appropriate Docker container.
2. Everyone has to write ehrQL but only a much smaller subset of our users choose to use Python for their analysis code.
3. ehrQL is complex and unfamiliar whereas users who choose to use Python will, by definition, be more familiar with their own code, so autocomplete is much more valuable for ehrQL.
4. Python's backwards compatibility means that correctly parsing and error checking files intended for an older version is mostly unproblematic.

There's no immediate rush here: autocomplete for ehrQL currently works perfectly well in Codespaces despite the version mismatch. But there remains the risk of drift further down the line and, if autocomplete did break in Codespaces we might not immediately realise it because the tests are all in the ehrQL repository.

If we did do this then it would probably also make sense to have a daily scheduled action which checks that the Python version used here matches the one used by ehrQL.

[StevenMaude]

I had a brief think about this while working on #104.

One possible complication is that we currently pull the installed Python packages from the python:v2 image. It feels like that could be a problem (newer Python running older packages; some of which may use features that are removed), but I've not given it much more thought.

It would be nice if the "current" Python image and ehrQL image (and various other places we use Python) were in sync on the same minor version.

[evansd]

It would be nice if the "current" Python image and ehrQL image [...] were in sync ...

Would that really help though? From the users point of view the version which we declare to be current is pretty arbitrary. What matters for them is the version they're actually using for their project.

[StevenMaude]

It would be nice if the "current" Python image and ehrQL image [...] were in sync ...

Would that really help though? From the users point of view the version which we declare to be current is pretty arbitrary. What matters for them is the version they're actually using for their project.

I agree that a user shouldn't need to worry or care about this.

I meant more that having that uniformity is a benefit for us as developers. It's one thing we then don't have to consider or worry about. (Maybe the issue of packages I mention isn't an issue at all anyway. But it certainly wouldn't be an issue at all if the same Python version was in use everywhere.)

(I should add: I'm also for making this change if we can do so without breaking anything.)