1
0
mirror of synced 2026-10-23 07:08:55 +03:00
Files
pgadmin4/pkg/python-version.txt
Dave Page 432d74bf1b Decide the Python version in one file rather than three places
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.
2026-09-17 10:16:50 +01:00

27 lines
1.3 KiB
Plaintext

# The Python that pgAdmin builds against and ships.
#
# Every platform's packaging reads this file, so that a given commit produces
# the same interpreter everywhere rather than whichever one happened to be
# installed on the machine that ran the build, and so that a change of version
# arrives as a reviewable commit rather than as a settings change somebody made
# on a build agent.
#
# The format is deliberately dull: KEY=value, one per line, with # comments. It
# has to be read by a batch file, a shell script and occasionally a person, and
# anything richer than this would need a parser in at least one of those.
#
# PYTHON_VERSION is the exact CPython release, and is the only value the macOS
# build needs, since relocatable-python fetches the framework from python.org
# by version. The Windows build fetches a relocatable distribution from
# astral-sh/python-build-standalone, whose releases are dated rather than
# versioned, hence the second value; it then ships the matching embeddable
# distribution from python.org.
#
# The two must be changed together, because the archive names embed both, as
# cpython-<PYTHON_VERSION>+<PYTHON_BUILD_STANDALONE_TAG>-<platform>.tar.gz, and
# any given tag only carries the CPython releases that were current when it was
# cut.
PYTHON_VERSION=3.13.15
PYTHON_BUILD_STANDALONE_TAG=20260901