Skip to content

Update mini-installed addon Python dependencies on Update click - #2487

Open
dsblank wants to merge 2 commits into
gramps-project:maintenance/gramps61from
dsblank:addon-mini-installer-upgrade
Open

Update mini-installed addon Python dependencies on Update click#2487
dsblank wants to merge 2 commits into
gramps-project:maintenance/gramps61from
dsblank:addon-mini-installer-upgrade

Conversation

@dsblank

@dsblank dsblank commented Aug 3, 2026

Copy link
Copy Markdown
Member

[I'm going to call this a bug fix, because if a pip-installed package needs to be updated, you'd have to find it, delete it, uninstall the addon, and re-install. This PR does require that the addon itself be updated too, but then can update the pip-installed package. -Doug]

Summary

  • Clicking Update on an addon previously only refreshed the addon's own code — a Python module dependency already mini-installed via the stdlib PyPI wheel installer (or pip) was never checked against a newer release, so it could go stale indefinitely.
  • install_package() in gramps/gen/utils/pypi.py gains an upgrade mode: it looks up the newest version on PyPI, and if the installed copy is older, removes the old dist-info/files (only when they live under the target mini-install directory, never touching system/venv installs) and reinstalls.
  • The Update button now runs dependency installation in this mode before refreshing the addon code; the pip subprocess path passes --upgrade for the same effect on source/snap installs.

Known limitation

The Update button's visibility is still driven only by the addon's own code version (_v vs v in gramps/gui/plug/_windows.py), not by whether a declared Python dependency has a newer release on PyPI. So this only refreshes a stale dependency as a side effect of clicking Update for some other reason (e.g. the addon's own version was bumped) — it does not yet surface "this addon's Python dependency is outdated" as its own condition. Keeping that out of scope for this PR to keep it simple; a follow-up could have the addon row check its rm packages against PyPI independently.

Test plan

  • python3 -m unittest gramps.gen.utils.test.pypi_test -v (200 tests, existing coverage)
  • python3 -m unittest gramps.gen.utils.test.pypi_e2e_test -v (14 tests, including 2 new upgrade-mode tests against real PyPI)
  • black --check on all changed files
  • mypy on all changed files

🤖 Generated with Claude Code

Previously, clicking Update on an addon only refreshed the addon's own
code; a Python module dependency already mini-installed via the PyPI
wheel installer or pip was never checked against a newer release, so
it could go stale indefinitely.

install_package() gains an upgrade mode that compares the installed
version against the newest release on PyPI and reinstalls when out of
date, removing the old dist-info first so it cannot shadow the new
one. The Update button now runs dependency installation in this mode
before refreshing the addon code, and the pip subprocess path passes
--upgrade for the same effect on source/snap installs.
@dsblank
dsblank requested a review from a team August 3, 2026 20:09
@dsblank dsblank added this to the v6.1 milestone Aug 3, 2026
The CI runner has tomli already installed (pulled in transitively by
build tooling), so install_package()'s own already-importable guard
was swallowing the tests' setup calls before anything reached the
target directory, leaving it empty and failing both assertions.

Seed the fixtures with a new _force_extract() helper that downloads
and extracts a specific version directly, bypassing that guard the
same way TestDownloadExtractE2E already does. Since the test target
sits at sys.path[0], the seeded copy shadows any real installation
found later on sys.path regardless of environment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant