radian-software
Radian advices on forge
Radian has some advices that prevent the sqlite binary from being built when forge is loaded. Instead, delaying this to when forge-dispatch gets called.
The problem is that it also prevents the loading of the package emacsql-sqlite until forge-dispatch is called (even if the binary is already built), which breaks forge until then, e.g., issues are not displayed and any calls to forge fail.
One simple solution would be to require emacsql-sqlite instead of conditioning on it being loaded in radian--forge-get-repository-lazily, but I am wondering if there is a reason that this wasn't done in the first place.
Oh, erm. It's been a while since I set this up. What I was trying to avoid was forcing EmacSQL to be compiled just for magit-status to be opened. I guess I didn't realize that there were other entry points to Forge other than the dispatch key.
Maybe ideally it would check if EmacSQL has been compiled already, and go ahead and load it if so, and otherwise delay it until the user tries to interact with a Forge feature?
I guess the point is that the variable emacsql-sqlite-executable is not defined until you load emacsql-sqlite.
I am not 100% sure why you require that emacsql-sqlite be loaded in radian--forge-get-repository-lazily, rather than requiring it, to access emacsql-sqlite-executable.
Also, I am not sure that such hack is necessary at all.
The compilation of the binary seems to be in emacsql-sqlite-ensure-binary
which is called by initialize-instance in emacs-sqlite
which is called by make-instance in closql-db
which is called by forge-db.
If you want to avoid auto-compilation of the binary in magit-status you can remove the function forge-connect-database-once from magit-status-mode-hook, which in turn calls forge-db.
Also, in emacs 29 and later, the connection emacsql-sqlite-builtin-connection is used by default (as returned by (emacsql-sqlite-default-connection)) which should use the built-in implementation of sqlite which actually doesn't compile any binaries.