Does gschema.compiled really belong in the Git repository?

[ericzolf]

After modifying src/gtimelog/data/org.gtimelog.gschema.xml, I tripped over the error:

$ ./gtimelog 

(gtimelog:46277): GLib-GIO-ERROR **: 14:37:37.363: Settings schema 'org.gtimelog' does not contain a key named 'log-order'
Trace/breakpoint trap (core dumped)

I found out that calling make recreated src/gtimelog/data/gschemas.compiled which solved the issue, but I noticed that removing alltogether gschemas.compiled also solved the issue. According to https://stackoverflow.com/questions/56309056/is-gschemas-compiled-architecture-specific-can-i-ship-it-with-my-python-library it is only a cache file and shouldn't be shipped with the application but generated by packages on the fly.

So, should I/someone remove this file from the Git repository? And place it on the ignore list...

[mgedmin]

In general, I agree that generated files should not be committed to Git. The compiled schema here is an exception. I wish I'd written down why I made that decision in 13506c7. This Twitter mini-thread might be related. (Also wow, it took two years of internal agonizing before I said "eff it, I'm adding compiled files to git, let's just get it out".)

It was possibly related to making things work out of the box. My goals for gtimelog were (and, I suppose, still are):

• given a machine with Python and PyGobject installed systemwide, I should be able to git clone the repo and run ./gtimelog, and it should work with no extra steps
• I should be able to pip install gtimelog (e.g. using pipx) and it should work on a system that has Python and the relevant GTK introspection typelibs installed
• (bonus) I should be able to pip install -e ~/src/gtimelog after cloning, and have it run out of the box, given a system with Python and GTK typelibs

I still have code to run glib-compile-schemas during gtimelog startup, added a year before that other commit (in 15f151d).

I see two ways forward:

• extend that code to check timestamps and regenerate the compiled schema if the schema source has a newer mtime
• remove gschemas.compiled from git and see what breaks?

(Or we could do both. Editing the source XML and forgetting to run make before restarting gtimelog is a possible failure mode in the development cycle.)