mirror of
https://github.com/pyMC-dev/pyMC_Repeater.git
synced 2026-10-31 04:01:59 +01:00
Thibault VINCENT
9c1b3b4650
The OTA updater could stamp a build with a version that did not come from
the code being installed, which left nodes stuck on a version they could
not upgrade away from.
Two independent defects combined:
* _fetch_latest_version() returned the newest repository tag whenever the
GitHub lookup failed. On a dynamic channel such as dev, that value is
from a different branch entirely, so the UI reported "up to date" while
tracking a channel that was hundreds of commits ahead. The fallback also
swallowed _RateLimitError, defeating the backoff path already built for
it.
* _do_install() then passed that predicted version to setuptools_scm as
SETUPTOOLS_SCM_PRETEND_VERSION (and as the pretend-version argument of
pymc-do-upgrade), so pip built the channel's code but recorded the
predicted version as the installed one. When the two matched, every
later upgrade — including Force Reinstall — resolved as "requirement
already satisfied" and did nothing.
Observed on a node tracking dev: installed 1.1.1, latest 1.1.1, no update
offered, while dev was at 1.1.2.dev201.
A version lookup that cannot be resolved now raises, so a failed check is
reported as a failed check instead of a wrong version, and the install
derives its version from the checkout pip clones.
The remaining pretend-version uses in manage.sh are scoped to this
distribution. The unscoped variable applies to every setuptools_scm-based
project built in the same pip invocation, not only ours: dependencies
normally arrive as wheels and are unaffected, but one built from an sdist
inherits our version. With it set, pip wheel on the portend sdist produces
portend-9.9.9; portend and jaraco.functools both build with setuptools_scm.
buildroot-manage.sh already exports the scoped variant.
Signed-off-by: Thibault VINCENT <root@devcat.org>