Scrap use of local git repo in diracx-config

[marianne013]

Generated from the matching diracx discussion.
On upgrading diracx, I discovered we still had the following hack in our code and without it, it doesn't work:

++ b/diracx-core/src/diracx/core/config/sources.py
@@ -120,7 +120,8 @@ class ConfigSource(metaclass=ABCMeta):
     ) -> "ConfigSource":
         """Produce a concrete instance depending on the backend URL scheme."""
         url = TypeAdapter(ConfigSourceUrl).validate_python(str(backend_url))
-        return cls.__registry[url.scheme](backend_url=url)
+        # hack
+        return RemoteGitConfigSource(backend_url=url)

We think we (nearly) arrived at a conclusion, but only nearly.....

Discussed in #700

^{Originally posted by sfayer November 7, 2025}
Hi,

We're working on the non-k8s diracx container deployment recipe and have run into some issues with loading the CS store... We've exported our existing CS into the diracx format and have it in a local git repo directory which we're initially bind mounting in as a read-only mount at /cs_store and setting DIRACX_CONFIG_BACKEND_URL="git+file:///cs_store?branch=master".

This doesn't work: The git+file handler runs into a number of issues:

• The bind mount point files are owned by "root", whereas the diracx container uses "mambauser" which trips out git's insecure file permissions check for the rev-parse command:

  diracx/diracx-core/src/diracx/core/config/sources.py

  Lines 251 to 252 in c265a47

  	sh.git(
  	"rev-parse",

• If we bypass the security checks, the checkout fails because we made it a bare repo.
• If we convert it to a normal repo, the checkout fails because the volume is read-only.
• If we make the volume read-write, the checkout fails because of the different file ownership.

We modified the code, to use the git+https "RemoteGitConfigSource" handler for the git+file case too and this works (and I suspect would also work better if this directory was shared across multiple hosts).

Our questions for discussion are:

• Is there actually a good use case for the LocalGitConfigSource class? It seems to me that in the majority of deployments RemoteGitConfigSource would work the same or better, even if the source is actually a local directory.
• If removing LocalGitConfigSource isn't an option, perhaps we could make using it optional instead? (For example offering 3 protocol types, say git+https and git+file using RemoteGitConfigSource and a new git+local option if you really want the LocalGitConfigSource behavior)?

We're not really sure how this is all going to work out if it needs to start pushing commits back: Getting the permissions all correct for writing a bind-mount on any platform seems to be its own challenge (but perhaps that isn't planned for a while and we can worry about that later?).

Regards,
Simon

Mentioning @marianne013

[aldbr]

Have you checked with the new pixi-based images (from diracx 0.12.0 IIRC)? It might solve your issue 🤞