Sync addons-source@maintenance/gramps60 with upstream (2026-05-17) - #17
Merged
eduralph merged 21 commits intoMay 17, 2026
Merged
Conversation
The class defines add_children_submenu twice (introduced in the same 2018 commit by Serge Noiraud). Python's class body executes top-to-bottom and rebinds the name on each def, so only the second definition is reachable; the first has been unreachable for 8 years. The dead copy contained the bare displayer.display(child) references that Ruff F821 flagged at L1239/L1241. The live copy already uses name_displayer.display correctly. Deleting the dead method removes the F821 warnings at their source and prevents a future reordering or merge from accidentally reviving the broken version. Behavioural impact: none. The live add_children_submenu at the previous L1528 (now L1473) is unchanged. Per Gary's testing on the unpatched code, the children submenu already rendered correctly — because the dead copy was never called. Thanks to GaryGriffin for catching the original PR's misdiagnosis of the runtime impact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`QuiltView/QuiltView.py:1266` constructs a fresh `Surname()` to
attach to a new `Name` when adding a child via the editor, but
`Surname` is never imported. Ruff (F821) flags it:
F821 Undefined name `Surname`
--> QuiltView/QuiltView.py:1266:26
The file already imports `Person, Family, ChildRef, Name` from
`gramps.gen.lib` — extend that import to include `Surname`. Without
it, the add-child path raises `NameError` instead of opening the
editor.
This PR addresses only the `Surname` F821. Two other F821 sites in
the same file (`displayer` on lines 1239/1241, where the call should
likely be `name_displayer.display(...)` rather than a top-level
`displayer` reference) are real-bug fixes and are deliberately left
out of this surgical lint PR — they need a small behavioural review
of their own.
Verified via `ruff check --select=E9,F63,F7,F82 --no-fix
--exclude='*.gpr.py' QuiltView/` (Surname F821 removed; the two
unrelated `displayer` F821s remain) and `python3 -m py_compile`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PhotoTaggingGramplet.py does `from gi.repository import GExiv2` at
module load but the .gpr.py declared no requires_gi, so neither the
Addon Manager nor the addons-source CI auto-derive step knows the
typelib is needed.
The earlier revision of this PR declared `requires_gi=[("GExiv2",
"0.10")]`. That is too strict: unlike EditExifMetadata, this addon
never calls `gi.require_version("GExiv2", ...)` — it imports whatever
typelib version is available. gen/utils/requirements.py:_test_gi does
an exact `gi.require_version` match, so a hard "0.10" pin would report
the dependency as unmet on any system carrying only a newer GExiv2
(e.g. 0.14), blocking an addon that would in fact load fine.
requirements.py:check_gi splits the version field on "," and accepts
the addon if any listed version is present. Declaring
`"0.10,0.12,0.14"` therefore matches the addon's real requirement —
"some GExiv2 typelib" — across the versions in circulation. (Listing a
version that happens not to be installed is harmless: check_gi just
tries the next.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per GaryGriffin's testing on Mac 6.1, GExiv2 0.16 is shipped in the Mac AIO bundle. The earlier "0.10,0.12,0.14" list rejected that system because gen/utils/requirements.py:_test_gi exact-matches each candidate via gi.require_version, and 0.16 was not in the list. Adding 0.16 to the comma-separated form clears the gate on current Mac AIO. Each future GExiv2 minor release still requires another list entry — the structurally correct fix (dynamic version detection in the addon's own code, per PR gramps-project#829) is being raised separately on the gramps61 branch where the addon code can be modified to match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Strip 1 trailing-whitespace line from PhotoTaggingGramplet.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on PhotoTaggingGramplet/*.py = 0 matches - string-token comparison: 0 multi-line strings affected
Strip 1 trailing-whitespace line from relation_tab.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on RelID/*.py = 0 matches - string-token comparison: 0 multi-line strings affected This PR is scoped to trailing-whitespace only. The separate F821 in relation_tab.py (Undefined name `ErrorDialog`) is covered by PR gramps-project#858.
Strip 1 trailing-whitespace line from TimelinePedigreeView.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on TimelinePedigreeView/*.py = 0 matches - string-token comparison: 0 multi-line strings affected
Strip 1 trailing-whitespace line from lxmlGramplet.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on lxml/*.py = 0 matches - string-token comparison: 0 multi-line strings affected This PR is scoped to trailing-whitespace only. The four remaining ruff errors in lxmlGramplet.py (F821 self×2, F632 is/== ×2) are covered by separate PRs gramps-project#874 and gramps-project#837 per the one-logical-fix-per-PR convention.
Strip 2 trailing-whitespace lines from CensusCheckQuickview.gpr.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file (gramps exec()s .gpr.py at plugin-registration time, so syntactic validity is what matters) - post-strip grep for '[ \t]+$' on Form/*.py = 0 matches - Form's existing unit suite (Form/tests/test_form_validator.py and Form/tests/test_integration_form.py, 48 tests total) passes against the cleaned tree via ./scripts/ubuntu/run-addon-unit.sh Form - string-token comparison: 0 multi-line strings affected (both strips are on `register(QUICKREPORT,` argument lines)
Strip 2 trailing-whitespace lines across GrampsChat.py and chatbot.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on both touched files - post-strip grep for '[ \t]+$' on GrampsChat/*.py = 0 matches Multi-line string content audit: both strips occur inside the HELP_TEXT module constant (GrampsChat.py:19-60 and chatbot.py:23-64), specifically the trailing space on a single line inside a triple-backtick markdown code block (`export GRAMPS_AI_MODEL_URL="<ENTER URL HERE>"`). HELP_TEXT is consumed only by append_message(HELP_TEXT, is_user=False) for display in the chat panel; trailing whitespace at end-of-line in rendered text is invisible. No equality/hash check references HELP_TEXT.
Strip 3 trailing-whitespace lines from DescendantsLines.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on DescendantsLines/*.py = 0 matches - string-token comparison: 0 multi-line strings affected
Strip 9 trailing-whitespace lines from diffhandler.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on GrampsWebSync/*.py = 0 matches - string-token comparison: 0 multi-line strings affected
Strip 294 trailing-whitespace lines across 5 files (concurrency.py,
postgresqlenhanced.py, schema.py, schema_migrations.py,
undo_postgresql.py) to clear the CI Lint job's whitespace check.
Verified:
- git diff -w against upstream/maintenance/gramps60 = 0 lines (proves
the change is whitespace-only)
- per-hunk audit: every '-' line equals the '+' line plus [ \t]+$
- ast.parse() clean on every touched file
- post-strip grep for '[ \t]+$' on PostgreSQLEnhanced/*.py = 0 matches
Multi-line string content audit (tokenize STRING comparison before/after):
38 multi-line literals had content modified. Classification:
- 36 docstrings (function/class/method """...""")
- 2 SQL queries passed to cur.execute("""...""") —
postgresqlenhanced.py:2138-2143 (SELECT against pg_tables) and
undo_postgresql.py:247-252 (INSERT INTO ... RETURNING change_id)
Docstrings are consumed only by help()/Sphinx, which ignore trailing
whitespace inside RST. PostgreSQL is whitespace-insensitive between SQL
tokens, so trailing space inside the heredoc has no semantic effect on
either query. Grep over PostgreSQLEnhanced/ for assertEqual/assertIn/
assertRegex returned 0 hits — no test references these strings.
Strip 21 trailing-whitespace lines from ArchiveAssist.py to clear the CI Lint job's whitespace check. Verified: - git diff -w against upstream/maintenance/gramps60 = 0 lines (proves the change is whitespace-only) - per-hunk audit: every '-' line equals the '+' line plus [ \t]+$ - ast.parse() clean on the touched file - post-strip grep for '[ \t]+$' on ArchiveAssist/*.py = 0 matches - string-token comparison before/after shows 0 multi-line strings whose content changed (all strips were on code-bearing or blank lines, not inside string literals)
`RelID/relation_tab.py:728` calls `ErrorDialog(_("Permission problem"))`
when the working directory is not writable, but `ErrorDialog` is never
imported. Ruff (F821) flags it:
F821 Undefined name `ErrorDialog`
--> RelID/relation_tab.py:728:17
The file already imports `WarningDialog, OkDialog` from
`gramps.gui.dialog` — extend that import to include `ErrorDialog`.
Without it, the permission-error path raises `NameError` instead of
displaying the dialog.
Verified via `ruff check --select=E9,F63,F7,F82 --no-fix
--exclude='*.gpr.py' RelID/` (now passes) and `python3 -m
py_compile`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
importData() references `tmg_dataset` in `'tmg_dataset' not in locals() or tmg_dataset is None`, which Ruff flags as F821. The earlier revision of this PR silenced it as a "false positive," reasoning that the short-circuit makes the reference safe. That justification was wrong. The F821 is real: the multi-dataset GUI selection branch earlier in the function builds and shows a dialog but the line capturing the choice (`tmg_dataset = selecteddataset`) is commented out, so `tmg_dataset` is never bound on any path before this guard — it always falls through to only_first_dataset(). The guard is still runtime-safe (the `not in locals()` test short-circuits), so the noqa stays — but its inline comment now states the real situation: incomplete GUI code, F821 silenced pending its completion or removal, tracked separately. No behaviour change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated nightly sync from
gramps-project/addons-source@maintenance/gramps60. Generated by .github/workflows/upstream-sync.yml on the testbed.