Investigate removal of PyGObject from bundled plugins
PyGObject seems to be a bit under-maintained these days and we often find ourselves running into very strange behavior with GObject Introspection that can cause difficult to track down memory corruption bugs.
It might be nice to investigate how we can replace our Python-based plugins without requiring a lot of code to be written in C. Particularly by moving more helpers (such as IdeDiagnosticTool or IdeLspService) into libide-foundry
.
Things we won't do as part of this:
- Have anything in Vala. We have a moratorium on vala code in Builder and I 100% won't allow new code in-process w/ Vala.
- Rewrite all of them in JavaScript (this would first require writing and vetting a new
PeasModuleLoader
for GJS in libpeas first anyway. - Writing them in Rust (which would require a two step linking process to be able to generate Gir -> generate bindings -> compile plugins -> link again).
Things I'd consider now, short of new ideas:
- Writing them in C using more simplified interfaces to reduce how much "guts" are written in C when it comes to parsing results.
- Write a multi-process shim for the common libide addin interfaces that matter and move the processing work out of process. This is sort of what
gnome-builder-worker
used to do which I don't want to bring back.
I'm not completely against the idea of GJS if we could have a vetted Peas loader, but that will both take time to write and time to debug and get stable first. I also don't love the idea of having both JavaScriptCore and SpiderMonkey in the same process.
Plugins Containing PyGObject
-
blueprint - Just an LSP bridge -
clangd - Just an LSP bridge -
go-langserv - Just an LSP bridge (renamed to gopls
) -
intelephense - Just an LSP bridge -
jedi-language-server - Just an LSP bridge -
ts-language-server - Just a LSP bridge -
vls - Just an LSP bridge -
gvls - LSP bridge not yet modernized, not sure if we should even keep since we dont distribute it -
buildstream - Build system plugin, very minimal pipeline additions -
cargo - Combination of port to C + creation of simplified build system abstract base class -
copyright - Easy plugin to port to C -
eslint - Easy plugin to port to C -
find-other-file - Port to C, rather easy -
gjs-symbols - Port to C, I have a branch around somewhere doing most of it (See wip/chergert/gjs-in-c) (Deleting because it's broken, see gjs#482 (closed)) -
gradle - Not to difficult to port to C -
gvls - We don't even ship this plugin, so it might be a candidate to push out-of-tree -
html-preview - This one is complex because of sphinx auto-install. We can probably just delete that code because we don't care much at all about shipping on distros. We bundle sphinx in Flatpak. -
jhbuild - Runtime provider, and not a complex one at that -
make - Build system (easy to port) + template provider (slightly more annoying to port, but not too bad if we redo it with a base class to share w/ meson-templates) -
maven - Fairly small build system to port, not too much work -
meson-templates - This has a bunch of stuff, primarily around how we setup our core templates. We could probably push a lot of this to an out-of-process utility program and consume a JSON definition of available templates. -
mono - Just a pipeline addin to add an error regex. Super easy to port. -
npm - Small build system plugin, easy to port -
phpize - Small build system plugin, medium/easy to port -
rls - We could probably just delete this plugin, we have rust-analyzer now and use that from SDKs -
rstcheck - Very easy to port to C -
rubocop - Very easy to to port to C -
stylelint - Very easy to port to C -
vala-pack - Pipeline error regex + indenter. The indenter should be rewritten for GSV 5 and pushed upstream into gtksourceview/indenters/vala/ so the community can help maintain. -
waf - Build system plugin to port to C, medium/easy to port
First Steps
- Write a simplified IdeBuildSystem base class / PipelineAddin helpers based on what all the python-based build systems are doing. They seem to be doing some fairly similar stuff. If it's not really that helpful, fine to just do a 1:1 object port to C.
- Figure out how we can do simple LSP bridges with much less C code (remove the boilerplate, use XMACROs, etc). Rewrite rust-analyzer to use this too along with the other LSP bridges.
- Port c/python/vala indenters to GtkSourceView and push upstream.
- Create a project template base class that can be shared across meson-templates/make plugins.