Proposal regarding Plugins, their structure and the AssetLib

[AlansCodeLog]

I was initially just going to file an issue over at godot-docs regarding the missing plugin submission guidelines, but the more I've worked on a plugin the more I realized there are wider issues than the missing documentation, like the current recommended structure for the plugins (addons/author.pluginname/).

If you have a demo project for your plugin, it's tempting as I did to just put this all in one repo, except as I was told, a plugin can't be a project, which okay, makes sense. So I separated the plugin demo project/test scenes into another repo (because custom actions set in the project.godot file were needed for the demos to work). The problem now becomes working on the addon from within the plugin's demo repo. I cannot for example, add the plugin as a git submodule because of the root addon folder. The only work around I've found is to symlink the plugin's folder. But then this means that I have to somehow keep track of which commit corresponds to which plugin version (since the godot project doesn't keep track of this).

My proposal is a plugin should just be a repo's root (e.g. Blender plugins are like this). The author's name should not factor in¹ (though the plugin.cfg could contain info regarding the author, repo, demo repo, etc which Godot could present to the user if necessary). Readme's, licenses, etc should always be there right along with the plugin. Demos should always be separated. There should only be a finite number of places a plugin can be installed (addons, assets, etc), and this could be set when submitting to the asset lib (it could be determined by it's category/type?), or maybe it could be in the plugin.cfg file.

This all excludes templates, of course, which can remain as they are.

1. The reason I think the author name should not factor in is just because it's cleaner since the default name for clones/submodules is just the repo's name.

This has several benefits:

• Easier development. Plugin can be cloned directly inside a project or set up as a git submodule.
• Things that are not project templates/demos more obviously cannot be projects.
• Godot could eventually manage the placement of the plugins. If placement is set from within the plugin, this could be known regardless of where the addon came from (it could be dragged/dropped or imported from a zip like Blender).
• Where different types of addons go would be standardized and it would be the developer's responsibility to set it correctly.
• The user would usually not have to bother unticking any extra downloads, etc.

More benefits (edits):

• Documentation and licenses would always be clearly attached to the plugins. This will be especially useful if/when the editor can open other files.
• It would be easier to change/improve other people's plugins. Even if they were gotten from the AssetLib or a zip. I's still possible to init a repo, fetch changes, and keep your changes. From there you could do a pull request or even just keep pulling new updates over your changes.

Of course, this is just an idea. I don't know if there are situations where this might cause problems.

The only issue I can see is that demo repos with submodules would not contain their plugins unless git cloned recursively, but this could be fixed when some kind of plugin management is implemented. If the project kept track of it's plugins and their versions, it could auto-install plugins when the files are missing. This would also make it easy to reuse projects as templates, including it's plugins.

[Zylann]

I develop my plugin like a project having only an addon/zylann.thing folder, and I test it using a demo folder within the plugin itself, which is the main scene. I expect users to uncheck the project.godot when they install it, but it's not very nice because it's not stated explicitely anywhere and easy to forget when you are a newbie. I could add it to my gitignore though, which means only the plugin and its folder remains... ah no, the README.md is still at the root, otherwise I can't have a nice Github page :p

[vnen]

BTW, I recently learned that you can exclude files from the zip download from GitHub by using the .gitattributes file (see vnen/godot-tiled-importer#75).

[AlansCodeLog]

@Zylann Yeah, that's almost exactly how I started out. Maybe I was too extreme with "all demos should be separated". I don't see too much of a problem with small demos (especially if they are tests) inside the plugin folder so long as they work out of the box, but there can come a point where they get out of hand or like I did, or you need the project.godot file.

But let's say I use the .gitattributes to ignore it but still track it. Any readmes, etc still have to be at the root of the repo. I forgot to explicitly add this to the list of benefits, but say the user does want to download the documentation, they can't if it overwrites their files. If the plugins were self-contained repos, the documentation would be right there alongside the plugin (also hopefully someday the editor will be able open them).

I was also thinking of any other possible solutions and switching to some global plugin system could eliminate many of these issues as well because then a plugin could theoretically be housed inside a demo project, but then what to do then when the user wants to modify the code? There it gets messy again.

This way, there's another benefit, let's say you download a plugin, you find a problem. You can either clone the repo or a fork, or if you already made changes over a download from a zip/assetlib it's still possible to init a repo, fetch changes, and keep your changes. From there you could do a pull request or even just keep pulling new updates over yours (in the case the change is project specific). All from within your project, other projects could still use other versions.

[bojidar-bg]

The only problem with this solution (which was discussed in some other issues, BTW), is that all paths in Godot's scenes and scripts are scoped to the project, and are not relative. That would mean that if the plugin is put in the wrong folder, bad things would happen.

On the other hand, we might enforce a "path" field in the plugin.cfg file, which would be checked for mismatches. Going further, we can make it a asset.godot file, so it can be used for non-addons as well.

[AlansCodeLog]

which was discussed in some other issues, BTW

Has it, I didn't find anything, can you link? I found discussions on global plugins (which as I mentioned only gets rid of some problems. I'm not to fond of it as a solution), but nothing similar to what I'm proposing.

The only problem with this solution [...] is that all paths in Godot's scenes and scripts are scoped to the project, and are not relative. That would mean that if the plugin is put in the wrong folder, bad things would happen.

I'm not sure what you mean? Plugins would remain relative to the project. Paths would be set by the developer somewhere (I mentioned the plugin.cfg because I knew about that, but it could be an asset.godot if that's better, anything really). That file would tell Godot ALL the info regarding the plugin, including where to put it. If it's in the wrong place on startup (e.g. you clone it into the project root instead of the addons folder) it could either be moved (since it is just a folder, there's little danger in assuming a folder containing a plugin.cfg is in fact a plugin and contains everything needed for it to work) or it can just not register (if it's not registered can it do any harm?)

Would there be any problems with this?

[bojidar-bg]

@AlansCodeLog Well, I can't think of potential problems, so I'm going to discuss it with the other devs. Having the readme, etc. of the addon inside addons/xx/ is going to solve a lot of headaches.

[reduz]

I was thinking about the following, let me know what you guys think. Of course, this breaks compatibility but it may be worth it.

When a user creates a project in Godot project manager, user can choose between creating a project or a add-on

If creating an add-on, the following will happen:

• In the project root, instead of "project.godot" a file named "addon.godot" is created instead.
• When editing an add-on, all processes for saving scenes, resources, etc. will operate using relative paths. Godot could automatically detect that it's saving into an add-on folder and save paths as relative.
• Alternatively, instead of saving paths as relative, we could add a new type of path: addon:// which is still absolute, but refers to an add-on. This needs to be discussed to see what solution is better (probably this one, as relative paths can be tricky from my experience).

Now, when you install Godot into a project, the following might happen:

• You can choose where to put the addon, no need to be any longer restricted by the addons folder or using unique paths
• No files will be stepped/overwriten
• Addons NEED to be enabled somehow, so there should be a setting in project.godot pointing to the list of addons enabled.
• ProjectSettings editor will lift data from the enabled add-ons folders and it will keep track of which settings come from where, so settings that come from an addon are not saved in project.godot
• Settings saved to project.godot would logically always override settings in addons (it does not make sense for an add-on to override a project setting, but overriding addon settings in a project does make sense).
• On export, all settings are combined

This would allow you to add stuff like new input bindings, translations, etc. that come from add-ons. Of course one problem with this is that I'm not sure if all meaningful settings right now are saved in individual properties. It will work for input bindings, but It may not be the case with translations, or translation remaps, which is a problem, this will need to be looked at.

What do you think?

[reduz]

Continued here: #19178

[willnationsdev]

Referenced similar topic earlier: #12153

[Calinou]

Closing in favor of godotengine/godot-proposals#554, as feature proposals are now tracked in the Godot proposals repository.