Python 3.14 has to wait: the Windows build needs pywinpty, which is held
at 2.0.x for andfoy/pywinpty#545, and 2.0.x cannot be built for 3.14.
Note that beside both pins.
Which Python pgAdmin builds against and ships has until now been settled in
three unrelated places. On Windows, Make.bat used whatever %PGADMIN_PYTHON_DIR%
pointed at, which the buildfarm's Jenkins node configuration injected, and then
derived the embeddable distribution it actually ships from that interpreter's
own sys.version. On macOS, pkg/mac/build.sh defaulted to a version of its own
whilst the workflows overrode it with a third, copied from the buildfarm's
DEFAULT_PYTHON_VERSION. Locally it was whatever the developer happened to have.
A single commit could therefore ship different interpreters on different
platforms with nothing anywhere announcing it, which nearly happened: a workflow
that discovered Python from the PATH would have shipped 3.14 on Windows against
3.13 on macOS.
The version now lives in pkg/python-version.txt, which every platform's
packaging reads. It is a file in the tree rather than a GitHub variable because
a local build has to read it too, and because a change of interpreter should
arrive as a commit somebody can review rather than as a settings change made on
an agent. The format is KEY=value with # comments, dull on purpose: it has to be
parsed by a batch file, by a shell script and occasionally by a person, and
anything richer would need a parser in at least one of those. It carries both
the exact CPython version and the python-build-standalone release tag, since
that project's releases are dated rather than versioned and the archive names
embed both.
Make.bat no longer depends on an installed Python at all. It downloads the
relocatable distribution named in that file, unpacks it into the build tree and
installs virtualenv into it, then fetches the matching embeddable distribution
from python.org for what actually ships, so the two can no longer disagree.
python-build-standalone suits the signing host particularly well, being a plain
tarball rather than an installer and so raising no UAC prompt, which matters
because an elevation dialog in that machine's auto-logged-in session waits
forever for somebody who is not there. curl.exe and tar.exe have shipped in
Windows since 1803, so nothing needs installing to bootstrap it. Both Windows
workflows consequently lose their Python setup, and the signing host needs
neither a Python, nor a virtualenv installed into it, nor the
PGADMIN_PYTHON_DIR repository variable.
macOS only reads the version. It still builds its framework with
relocatable-python, because python-build-standalone's relocatable distributions
are not framework-shaped and replacing what is shipped there would mean
reworking the codesigning and the @loader_path rewriting in _fixup_imports,
which is a job of its own.
The version itself is unchanged: 3.13.15 is what the released installers
already carry, and this makes that existing choice explicit rather than a
different one.
