godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Add an abstract PackageManagerAdapter class that gdextension and plugin authors may implement. #10955

Open ArchercatNEO opened 3 weeks ago

ArchercatNEO commented 3 weeks ago

Describe the project you are working on

A game using gdextension with gdextension and gdscript addons

Describe the problem or limitation you are having in your project

Godot currently only understands 3 types of path: res:// user:// and absolute paths. This means for people depending on libraries version control of such dependencies and of the project itself (as the addons must either be commited to git or a script to install them is neccesary) becomes a nuisance. If commited to res:// there will be large files commited to a git repo and a busy res://addons directory. If saved to an absolute or user:// path the project becomes less portable without additional effort to wrap it within a package.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding an ext:// path that follows the format ext://<package_id>/path/to/file where package id is any string that consitues a valid filename and that a registered PackageManagerAdapter will resolve into an absolute path. A PackageManagerAdapter will be an abstract class that allows implementers to use some existing package manager's infrastructure to resolve an ext:// path. I suggest this approach rather than implementing a new package manager for godot or adapting some existing package manager because implementing a package manager for godot would be a large maintenance burden and selecting an already existing package manger arbitrary and depending on the choice fail to meet user's needs. Users will then be able to select an adapter that meets their needs (out-of tree dependency resolution, version management of dependencies, compilation flags, etc.).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

As export templates do not contain editor features (and should be able to load files from ext:// paths) the EditorPlugin API cannot be used for this but I will use it for the sake of example. 2 new methods for EditorPlugin: void add_package_manager_adapter(PackageManagerAdapterPlugin adapter) and void remove_package_manager_adapter(PackageManagerAdapterPlugin adapter) These will be registered in some way such that they can be invoked to resolve ext:// paths A new abstract class PackageManagerAdapterPlugin with abstract methods: String _globalise_path(&String p_path, &String p_project_path) and PackedStringArray _get_extensions(&String p_project_path) (so that .gdextension files need not live inside the project either) ProjectSettings::globalise_path will then internally use adapters registered by the EditorPlugin

If this enhancement will not be used often, can it be worked around with a few lines of script?

Scripting is not able to change how file paths are resolved in gdextensions, resource files or import files

Is there a reason why this should be core and not an add-on in the asset library?

Addons cannot implement the infrastructure for adapters. However the maintenance burden of adapting existing package managers will lie upon addon support rather than core support.

ArchercatNEO commented 1 week ago

https://github.com/godotengine/godot/pull/98544 would also be sufficient for this proposal as the paths could be added as apt://, nuget://, etc and a meta ext:// path could be implemented if that is more desirable than this proposal. If that proposal seems better for godot maintainers this one could be closed.