During the development of the intelephense lsp implementation the podman runtime I was using kept being unavailable each time the project opened. And builder would complain that the build configuration was broken because it couldn't find a provider for the selected runtime.
The cause of this is the asynchronous initialization of the podman runtime provider that has now way of letting the runtime manager know in time that it does provide the runtime that is configured (as far as I can tell).
The proposed fix includes a refactor of the can_install method. My understanding of this method is that it lets a runtime provider tell the manager that it wants to run some tasks while setting up the pipeline, but it can provide the requested runtime at some point in the future. This then triggers the bootstrap method which can be used to do some async setup tasks that are needed to provide the configured runtime. Because podman (in it's current state) isn't going to install anything the name can_install didn't make much sense anymore.
The actual fix for the issue is then relatively straightforward, we move the asynchronous initialization of podman to the bootstrap method. And let the manager know that we can provide a runtime with an id that is prefixed with podman: so it will perform the bootstrap and wait to enable the pipeline until that is done.
The reason this MR is a draft is because I'm not super familiar with the codebase, or glib/gobject, especially in C. So the main questions that I have now are:
- Does this initial refactor to
providesmake sense? - Is the way I'm passing the
runtime_idthrough to the bootstrap task the right way to do it? Or is there maybe a simpler way with task data or something similar?