Running an "Importer dialect" development experiment

Development Beta Testing
1

One of the imminent changes is the GEDCOM7 addon by @DavidMStraub.

But there were problems where the built-in filetype autodetect sees the .ged and overrides manually chosen GEDCOM7 Addon.

As mentioned in Feature Request 14071, I’d been wanting a vCard importer that supports v2.1 (which my smart phone uses) in addition to the v3. (Given that one of the fairly common assignments in primary school “Social Studies” class is to create a Family Tree, it seemed like students could import their contact list as a starting point with immediate family.) So expanding support to import/export all versions of vCard… but no new data types… seemed an obvious, simple task for an AI. And it would be a good test of issues when an Addon competes with a core plug-in.
This experiment was run because my hope to enhance the vCard import had not caught the interest of developer when mentioned in several Discourse postings since 2020:

So, after prompting Claude to assess the issues and possible options. We generated GEPS 048: Format Negotiation Layer for Import-Export Plugins

I pushed to consider some possible workarounds for while the core was being modified or if the GEPS was rejected.

  • Claude came up with a complex idea of a “Meta-Importer” plug-in. It seemed like a plumber’s nightmare and probably too fragile.
  • I suggested a low-investment option: fork the built-in plugin, enhance it as an addon, then manually “hide” the original with Plugin Manager enhanced.

Forking the built-in vCard3.0 importer and export plugins was fussy but straight-forward. And I fed to Claude to enhance, stressing that this was a test of the issues related to GEPS 048 and the “forking” workaround approach.

The enhanced version was generated and tested. (available in my GitHub repository of experimental addons. Warning: the enhanced vCard’s .gpr.py has some questionable code.) Using the addon had the expected problem: where the Import Wizard overrode the manual selection of the addon importer and export plugins; using autodetect and the original plug-ins instead.

Result: Manually hiding the original vCard Plugins proved to be a viable workaround.

image
image1492×832 96 KB

This is a lightly hacked Plugin Manager Enhanced. Extra diagnostics, extra filters, more searchable registration fields.

See also:
Discourse thread: Do Importers plugins allow fallbacks?

2

A lesson learned:

When Claude built the enhanced addon with an awareness of the GEPS 048 issues, it opted to get entirely too fancy with the Gramps Plugin Registration (.gpr.py) file. It added some code to attempt to automatically hide the built-in vCard plugins during registration. (That remains in the downloadable .tgz file.)

This code apparently did not work. And I am glad of that.

Code that is executable during registration seems like an unnecessary security risk of malware.

Now that JSON is a required library of Gramps, perhaps then Gramps should switch to a JSON based registration file?

Staying JSON might make building the Addon Manager’s addons-xx.json file easier too?

3

Yes. That is quite a good idea.

The executable code isn’t really a security issue since we can review it at the same time as the addon code. However, we don’t really want to have extra code in the registration files. Most of it should have been removed when I created the Addon Manager.

4

That’s true. Gary has been doing a great job vetting submissions to the addons-source repository.

But the concern is about other external projects, publishing Addons outside the purview of the gramps-project. Yes, there is still a similar risk of malware being concealed inside the main module. But the code insertion point is way further down the line. The plugin registrations happen before the main interface presents.