Dependency among GdExtensions

[kang-sw]

Out of mere curiosity, I wonder if there's any possibility in the future to implement dependencies between GdExtension binaries written in different languages? Being relatively new to exploring this repository, I'm not fully acquainted with the technical specifics. However, it appears that all GdExtensions register classes and methods with the engine. If the methods registered by GdExtensions are treated no differently from those of internal engine classes, wouldn't it be possible for the engine to accept classes registered by other GdExtensions at the time a Rust Extension is registered?

Of course, it's not possible to know which classes a GdExtension will register at compile time, but could we not retrieve metadata for classes already registered with the engine when a Rust GdExtension loads at runtime (based on some user-configurable flag setting), recreate bindings, and, based on this, support Rust bindings for other GdExtension Classes in the next iteration?

I'm not entirely sure, but I presume there must be a way within the engine to specify the load order between different GdExtensions. Consequently, unless a user updates their plugins, the bindings themselves would likely be deterministically generated.

[GsLogiMaker]

I've been thinking about this exact issue. I've not attempted implementing this, but theoretically if you provide a header for your GDExtension API then another compiled language could use that to interface with it.

Alternatively, you could use Godot objects and use the call function to use any exposed methods. This would be the simplest solution and works for any language, but you would be sacrificing type safety and maybe performance.

[Bromeon]

This might be more something for a Godot proposal than for godot-rust 🙂

But yes, we had this discussion in the GDExtension team, and I agree it would be quite valuable.
The good news are, this is already partially supported, even though quite manual:

1. Navigate to a Godot project directory, with a project that uses extensions (i.e. has one or more .gdextension files).
2. Invoke Godot 4 on the command line, as: godot4 --headless --dump-extension-api
3. The resulting extension_api.json contains also symbols from the extensions.

Now, I haven't tried using that extension_api.json as input for gdext, and manually overwriting the file would likely be brittle. What you could try however, is setting GODOT4_BIN only inside the project and making sure the Godot executable is run in the working directory of the project.godot file. That way, it should pick up additions from extension.

Maybe we can think about ways to support this workflow better from gdext.
Don't hesitate to open a Godot proposal to get the ball rolling for a proper feature in that regard.

[Bromeon]

Maybe worth noting, GDExtension has not really been designed for a full ecosystem, meaning there will be several challenges:

1. I'm not sure if the load order of extensions is deterministic.
   • There is the file .godot/extension_list.cfg which could possibly be used to override the ordering.
2. There is no package or dependency manager for extensions, no central repository and no versioning scheme.
   • People would need to ensure compatibility by hand or through custom scripts.
   • Cargo could help for Rust extensions, but likely, the majority of extensions will be written in C++. And then there's Go, Swift, Python, Kotlin... consolidating all the build systems is near-impossible unless you go for heavyweight solutions like Bazel/Buck2/...
   • It will be hard to establish any conventions (on source repos or versions) unless they are part of official GDExtension itself.
3. Godot has no namespacing. If two extensions define the same class, they can't be loaded together.
   • Something like prefixes might help, but it may also make usage more complex.

That said, we don't need to go the full route to be useful, even manually depending on extensions that were hand-selected could be a nice addition.

[kang-sw]

GDExtension has not really been designed for a full ecosystem

Aha, that was why I need to look for Godot proposals for this ... Thanks, now that makes a lot of sense! My curiosity is fully resolved; may I close this issue?

[Bromeon]

You can gladly start a discussion in a proposal, but maybe we can keep this open for now, for "bridge-the-gap" solutions on godot-rust side 🙂