This appears to answer my questions 1 and 2. Thank you 
See betty/test.py at gramps-api · bartfeenstra/betty · GitHub for a minimal working example.
1 Like
In the past, some packages have been generated for Suse OS, by spliting core (with GUI) and translations. I suppose it is still possible to generate a simple “cli” version according to current ecosystem? That’s a packaging stuff.
Maybe only some plugins (reports, tools, gramplets) need gtk?
(cf. Look, without GUI! Friday, June 19th, 2009 at 3:47 pm by Benny)
Jérôme
After re-reading my question, i realize the point was unclear.
I was curious whether Bart wanted to leverage an existing full Gramps install and its active tree (regardless of whether Gramps was running at the time or not), wanted to use a mimimal Gramps engine (with Import/Export plugin) as an external file conversion utility, or use the Gramps engine as a foundation handling database function while Betty acts as an interface.
Gotcha.
Primarily I want to use Gramps for conversion of files to its own data model, which I can then import. That gives me feature parity with Betty’s current capabilities (which uses XML parsing), and introduces support for additional file types in one go.
Once that’s up and running, I imagine it should be easy enough to skip the whole file import and pull existing family trees from the user’s existing Gramps desktop installation as well, but that means I need to find out how to connect to said user’s Gramps database.
1 Like
Yes, a core library is one of our long-term goals. We can certainly discuss this for inclusion in v6.1.
2 Likes
Integrate with Gramps' APIs instead of parsing Gramps XML by bartfeenstra · Pull Request #2444 · bartfeenstra/betty · GitHub is now ready for the main work: I added a barebones new loader with API parity with the existing one and applied the exact same test coverage to it as we already had for the existing loader. The next step is to work towards feature parity, e.g. import all the things the old loader imports, but through Gramps’ API instead of parsing XML. Once the tests pass, we can theoretically remove the old loader, and replace it with the new one.
2 Likes
I’m interested in similar functionality. I am developing packages that interact with Gramps, and for testing I have a small db checked into git (not good). I would prefer to have a Gramps XML file (all text) that I can convert to a DB on the fly, run the tests, and then delete.
Cheers
I seem to have run into yet another issue GrampsLocale complains additional instances are being created without the very first one being fully initialized yet. Due to the difficulties of isolating Gramps I have not been able to reproduce this locally yet, but here’s a CI run stack trace.
- No log messages or errors from Gramps, other than
GrampsLocale’s ownRuntimeError. - No recursion shown in the stack trace
- I’ve read through
GrampsLocale’s source and cannot immediately spot why this might happen.
Does anyone here have an idea of what this might be?
// Update: I have confirmed that this error shows up during macOS CI builds only. The Linux and Windows ones all pass on Gramps 6.0.0 with Allow Gramps' core to be imported without requiring GObject by bartfeenstra · Pull Request #2016 · gramps-project/gramps · GitHub applied.
@Nick-Hall Do you perhaps know where this GrampsLocale issue on macOS might originate?
I think that the macOS python is compiled without gettext support.
See PR #2046 for a possible solution.
1 Like
I’ll try that solution against the Betty PR branch and report back here
Good news! I tested your PR and it gets rid of the last remaining error the new Betty/Gramps integration was experiencing. It works on all Operating Systems now 
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.