FamilySearch Integration PR

Development
1

On Feb 16, the FamilySearch Integration PR was opened:

I decided to start a discussion here, rather than on github, as I don’t think we all have agreed on exactly what the criteria for the integration is, and wanted to make sure that @SourceAirbender (and others) understood our agreed upon expectations.

First, a lot of work has already been done so far! Almost 19k lines of code.

My first concern is that almost all of the code is in gramps/gui/fs/. I think this would make the functionality difficult to use from, say, gramps-web. I would think the code should be separated in the same manor as the rest of Gramps: lib for object definitions, gen for other code. This would be a large refactor, and probably will take quite a bit of time to separate the GTK gui parts from the business logic of the rest.

The PR requires database changes (we also have another PR with schema changes, so we’ll have to coordinate those changes). But the upgrade code should be standalone in the gramps/gen/db/upgrade code, as it may require more changes in the future.

The schema change adds a new table. But it might make more sense to add that info as a JSON field in the Person table. That also allows added similar fields to other tables in the future.

It might make sense to break the PR into three or more parts: the database API, the objects, the algorithms, and the GTK code. We need tests at all three levels.

I know @Nick-Hall created GEPS 046: FamilySearch Integration - Gramps (and a feature request from 2009 0003377: Connect and synchronize Gramps with the FamilySearch API. - Gramps - Bugtracker – Free Genealogy Software) but there is very little information there.

I also wonder how easily this will be to maintain over the years.

2 Likes
3

We are working closely with FamilySearch to meet their compatibility requirements and become a solution provider. This has meant that we have been willing to take their advice as far as the functionality is concerned. However, we do retain control of how the features are implemented.

I agree with two of your main points:

  1. I would expect to see the non-gui code in gramps/gen/fs/. This may be as simple as moving files and changing imports in some cases.
  2. It would be preferable to add JSON to the existing Person table rather than creating a new table if possible.

Discussions about how and when we deliver a FamilySearch compatible Gramps are ongoing. The outcome of these could affect our choice of splitting the PR or creating a GEPS branch.

1 Like
4

I’ll start working on those two points.

2 Likes
5

I’ll make comments in github about some other items. Briefly:

  1. All imports should be at top of file
  2. We use relative imports
  3. You don’t need try/except around imports that are part of gramps
  4. The upgrade should be moved as per above (this is required)

I’ve started an AGENTS.md that useful even if you are not using agentic AI. Notably docstrings, type hints, and Sphynx args.

If you have any questions or problems, let me know!

6

Sorry, can you clarify?

7

Currently, the upgrade code is in self._create_familysearch_sync_schema() But we need that extracted like the other upgrade paths into specific functions for version 22. Why? What happens if we want to change the FS schema further? We need another upgrade that will take a user from 22 to 23 (and beyond).

It will also help us merge the other version 22 upgrade PR mentioned above.

1 Like
8

6 posts were split to a new topic: GEDCOM date‑constraint semantics should not be propagated into Gramps

14

A post was merged into an existing topic: GEDCOM date‑constraint semantics should not be propagated into Gramps

15

A post was merged into an existing topic: GEDCOM date‑constraint semantics should not be propagated into Gramps