Right now, the parser is based on the DNASegmentMap gramplet code by @GaryGriffin in order to ensure mutual compatibility.

@GaryGriffin, would it be ok for you if I create a new pip-installable external pure-Python library that provides a function string → segments that we can use in both the DNASegmentMap grampet and in Gramps Web API? This way we could ensure that any note that works with one also works with the other, and improvements only have to be done once. Thanks to the new addon manager, it would be enough to provide a requires_mod to the new library in the addon.

Of course. The current gramplets that use this code are DNASegmentMap, DNAmatches and referenced in FamilyTreeDNA.

Mac (and Win, I think) gramps installs create a bundle so cannot run pip to add more libraries. They have to be bundled in the creation of gramps. I am thinking that this will mean that I cannot update DNASegmentMap until the 6.0 release to use this external lib. And will have to tell the bundlers to be sure to include this library going forward. Please provide instructions on how to test/use this when available.

I am aware of the MyHeritage format (these formats tend to change) and what I do is to import and then delete the leading strings. I cannot tie these names to grampsID, so they are useless. Or I use a spreadsheet and cut sections out and put into the correct Association Notes. Since MyHeritage puts multiple people in the file, the spreadsheet copy/paste was the most viable option I could think of.

You can also look at FamilyTreeDNA gramplet which requires a Note in the FT match to allow the match to be found in Gramps. I dont know if this gramplet is used often by people (created this summer). But it does a blind extract of the segment data and adds to the Association Note.

Are you planning on addressing how to tie the name in the segment file to a grampsID for MyHeritage?

Mac (and Win, I think) gramps installs create a bundle so cannot run pip to add more libraries. They have to be bundled in the creation of gramps. I am thinking that this will mean that I cannot update DNASegmentMap until the 6.0 release to use this external lib. And will have to tell the bundlers to be sure to include this library going forward. Please provide instructions on how to test/use this when available.

The alternatives are to include the library in core Gramps or create it as an addon library.

@GaryGriffin Would you like your DNA gramplets to be promoted to core Gramps?

I dont think DNA gramplets are ready for core at this point. They are still getting changes as more people use them with different sources of segment data. If in core, the update cycle becomes long.

Library in core makes sense. I don't know how an addon library would work. Would the DNA gramplets have a dependency on another addon? Would that make them harder to install for the typical user?

How about migrating this version to core (to get broad exposure) and spawning an "enhanced" version as an addon for evolution?

It could also serve as an experiment in having a Gramplet addon that directly supersedes a core plugin. (Like the Plugin Manager Enhanced addon library does for the Plugin Manager core.)

I agree it's too early to include this in core. An addon library (like libwebconnect) is not convenient for Web API, which is not an addon but a pip-installable package.

What we could do is to have an addon library and a pip-installable package that we keep in sync manually for the time being. It's not elegant, but at least easy to ship.

Just for my understanding as a non-Windows user: doesn't this code here do what it implies, namely installing Python dependencies for addons under Windows?

https://github.com/gramps-project/gramps/blob/maintenance/gramps52/gramps/gui/plug/_windows.py#L282-L306

What we could do is to have an addon library and a pip-installable package that we keep in sync manually for the time being. It's not elegant, but at least easy to ship.

pip-installable packages are a no-go for Mac (unless you are a Mac developer) since gramps is distributed as a bundle. I cannot speak to Win. I think a core library (for segments) may be the best answer long-term, but that pushes it to 6.0 . Are we looking for a 'now' solution and different long-term solution? That could get messy with maintenance.

Maybe do the library for web-api now and migrate it to core for desktop 6.0 . And modify the DNA gramplets in 6.0 to leverage the new library? So no changes for desktop until 6.0 . By then, the library could be stable and complete. This assumes that desktop testers could test it before 6.0 . How they test is dependent on how the web-api develops its library solution. I do not know the distribution of DNA users by platform, so cannot suggest a solution.

How about migrating this version to core (to get broad exposure) and spawning an "enhanced" version as an addon for evolution?

I dislike the idea of two versions. Maybe a better option would be to add a DNA chapter to the documentation (giving it more visibility) and discuss the various DNA features. The documentation would cover the library and the available gramplets.

Just for my understanding as a non-Windows user: doesn't this code here do what it implies, namely installing Python dependencies for addons under Windows?

Yes, that was the idea. It should work for pure python packages.

Maybe do the library for web-api now and migrate it to core for desktop 6.0 . And modify the DNA gramplets in 6.0 to leverage the new library? So no changes for desktop until 6.0 . By then, the library could be stable and complete. This assumes that desktop testers could test it before 6.0 .

I would be happy to do an early beta release of 6.0 if that would help.

Yes, that was the idea. It should work for pure python packages.

Ok, then I suggest to go for the pip-installable package since it will work on Windows and Linux.

For Mac, I strongly suggest we think about a way to enable pip-installable dependencies as well. It is very limiting for addons to not being able to leverage 3rd-party libraries and having support on Linux and Windows but not Mac would be a pity.

Ok, then I suggest to go for the pip-installable package since it will work on Windows and Linux.

It won't work on most Linux distributions either. You will get an error message saying that you should install the library using your package manager instead.

Ok, in that case I'll just implement the improvements in Web API for the moment and hope for a soultion to the gramplet at some later point in time.

Can you target desktop 6.0 for a segment library solution based on your Web API solution? Then all users will have it at that timeframe. I can update all the relevant gramplets for the 6.0 release.

I think I will also need to update documentation if the name fields are allowed for MyHeritage and FamilyTree DNA. See DNASegmentMap

A new module in gramps.gen.utils would seem to be the best place to put DNA related utility functions.