Open ArchercatNEO opened 1 month 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.
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 tores://
there will be large files commited to a git repo and a busyres://addons
directory. If saved to an absolute oruser://
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 formatext://<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 anext://
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)
andvoid remove_package_manager_adapter(PackageManagerAdapterPlugin adapter)
These will be registered in some way such that they can be invoked to resolveext://
paths A new abstract class PackageManagerAdapterPlugin with abstract methods:String _globalise_path(&String p_path, &String p_project_path)
andPackedStringArray _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 EditorPluginIf 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.