MNT: the docker/ files still use the paths they had before the 2024 move

[sujeito-operator]

docker compose up can't currently run the tests on any Python version, and I think all
three reasons are leftovers from moves the repo made for good reasons elsewhere. Four
commits, one finding each, so you can take any subset.

1. Both compose services mount the docker folder, not the repository

e50d6461 (#732) moved docker-compose.yml into docker/. Compose resolves relative
host paths against the project directory, which defaults to the folder holding the
compose file — so - .:/app mounts docker/ at /app, and docker/ has no
pyproject.toml and no requirements-tests.txt. Both services then run:

pip install . && pip install -r requirements-tests.txt && pytest && ...

which can't succeed there. - ..:/app mounts the repository root, which is what the path
meant when it was written at the top level.

2. python39-linux is below the floor the package declares

af7bbfff (#857) moved requires-python to >=3.10 in October. The compose file hasn't
been touched since November 2024, so it still asks for python:3.9, and pip declines a
Requires-Python mismatch before it builds anything. Renamed the service to
python310-linux at the same time so the key doesn't outlive the version again.

python312-linux is left exactly as it is. 3.12 is inside >=3.10 and works; it just
isn't one of the two versions CI runs. If you'd rather compose mirrored the matrix
(["3.10", "3.14"]), that's a one-line change, but it's your call and not a defect, so I
haven't made it.

3. FROM python:latest -> FROM python:3.14

This changes nothing about the image you build today. As of 2026-08-11 the latest
and 3.14 tags on Docker Hub are the same digest:

python:latest  sha256:3a9d2dd3f18e5c7a9d8de7b3659418a4ab848ccd409fb9e91ef9d7a6a3520ba7
python:3.14     sha256:3a9d2dd3f18e5c7a9d8de7b3659418a4ab848ccd409fb9e91ef9d7a6a3520ba7

What it changes is next time. .github/workflows/test_pytest.yaml runs
python-version: ["3.10", "3.14"], so the week 3.15 ships, latest moves the container
onto a version the matrix doesn't cover, and nothing announces it. Pinning to the minor
tag keeps the patch releases coming.

It's also the one build input your Renovate can't see. .github/renovate.json extends
config:recommended, whose dockerfile manager reads FROM lines — but a :latest tag
has nothing to bump, so it's skipped. Pinned, a 3.15 move arrives as a Renovate PR you can
read and merge, which is the same treatment the rest of the dependencies get.

4. The docs describe the pre-move layout

docs/development/docker.rst still says docker build -t rocketpy-image -f Dockerfile .,
which after the move gives the build a context with no requirements.txt in it, and still
says the compose file tests "python 3.9 and 3.12". Updated both, plus the FROM python:latest in the change-the-OS example, so the page matches the files.

One thing I noticed and did not change

docker/.dockerignore looks stranded by the same rename — it lists docs/, .github/
and Makefile, which are repository-root paths, but it's only read when the build context
is docker/. With the build command above the context is the repository root, and neither
.dockerignore there nor docker/Dockerfile.dockerignore exists, so nothing is excluded
and the whole tree including .git gets sent to the daemon. The fix depends on which
builder you're on, and unlike everything above that's a behaviour question rather than
something I can read out of a file — so I've left it alone rather than guess.

---

On provenance, since it matters for how much you should trust the numbers: I have no
Docker daemon on this machine, so none of this was built. Everything above is read off
files in this repository or off the Docker Hub API, both of which you can check the same
way I did. The two compose findings came from reading the tree after a Dockerfile linter I
maintain flagged the :latest base; the patch was prepared by an automated agent and
re-read against develop by hand before opening. Happy to close it if it isn't useful.