Manage Python dependencies for Gramps development through pip

[bartfeenstra]

This introduces a pip requirements file that:

• lets Gramps document its development dependencies in a single place
• ensures compatible versions are installed
• lets developers install these dependencies using a single command: pip install -r requirements-dev.txt

[QuLogic]

With PEP 735, this seems like it'd be better in pyproject.toml, but it appears Gramps hasn't moved to it yet.

[bartfeenstra]

Ideally, yes, but I'd see that as a potential (much bigger) follow-up because it would involve refactoring the entire distribution build. Until then, this will at least allow us to improve the development experience.

[numbersixnz]

In addition to the libraries mentioned in this PR's requirements-dev.txt, I had to install the following:

• PyGObject==3.52.3
• PyICU==2.15.1
• orjson==3.10.16

I'm also using Arch Linux, and that requires the installation of osm-gps-map from the AUR e.g.

paru -S osm-gps-map

I'm using Python 3.13.2.

[bartfeenstra]

Are those development-only dependencies? Because Gramps manages its production dependencies differently (through Operating System packages mostly), those would be out of scope for this PR.

[jralls]

Are those development-only dependencies?

No. PyGobject is needed to connect to Gtk, GLib, and Pango for the GUI. PyICU is required for localization. orjson is used to access json-formatted fields in the database.

[bartfeenstra]

Gotcha. So Nick (I think it was him) confirmed he wants production/runtime dependencies to be better managed in the future but that would require an overhaul of a bunch of code, so we decided to start with dev deps as a stepping stone that for now at least will make setting up development environments easier.

[jralls]

The only dependencies that might be considered development only are those that are imported (or have symbols imported from them) by test code but not application code. Based on the results of grep -r import *test* | sort -u there seems to be exactly one, unittest from the Python Standard library; there's also setuptools and its build and install commands, also from the Python Standard library. I don't think we can consider the Python Standard library as an optional dependency.

That's a long winded way of saying that there aren't any development-only dependencies.

[jralls]

The only dependencies that might be considered development only are those that are imported (or have symbols imported from them) by test code but not application code. Based on the results of grep -r import *test* | sort -u there seems to be exactly one, unittest from the Python Standard library; there's also setuptools and its build and install commands, also from the Python Standard library.

[jralls]

Now some general comments:
Installing black into the gramps-ci workflow is wrong, gramps-ci doesn't use black. black is invoked in the black workflow by a canned action, psf/black that takes care of importing it.

So all this PR does is add a layer of complexity to install the mypy static analyzer. IMO static analysis should be in its own workflow, and guess what, there's already a canned action for it.

[bartfeenstra]

Development environments also live on developers' own machines. This PR improves that, and allows other build processes such as CI runs to migrate to it as well. I can do that for Black if that's desired.