Describe the project you are working on:

The Godot Next plugin: a collection of scripts that are useful in a variety of projects (utilities, editor tools, singletons, nodes, resources, etc.).

Describe the problem or limitation you are having in your project:

Godot Next is large enough that it has a small network of internal dependencies (ranging from 0 and 1 all the way up to 6 in the rarest case). No big deal if you grab the whole thing, but if you just want to solve a problem with one script, then you might have to deal with dependency management, even inside a single addon.

This is a big headache, both for me as the maintainer and for users who get interested and then very quickly frustrated/turned off due to needing to deal with resolving out-of-nowhere dependency chains.

Describe how this feature / enhancement will help you overcome this problem or limitation:

The best solution would be to increase the granularity of addons in Godot Next and introduce dependency handling to Godot. After all, some people want it all; some want just the most necessary bits. The choice of whether to make users manually pick out the parts they want from the whole or piece together the whole from a bunch of parts shouldn't be a mutually exclusive one. Both options should be available.

Right now we have 1 addon with a wide variety of classes. Some are related to others; many aren't. But, they are all a package deal. They are part of Godot Next's brand of, "a generic extension to Godot."

Rather than that, I would rather have N addons, one for each class or minor collection of classes, and have each tiny addon declare the dependencies that it has on other addons. I would then want to be able to declare all of these addons to be part of a thematic/topical "package" that users can use to mass select a collection of other addons. These could be defined as part of an AssetPackage resource type for arbitrary creation and storage. The Godot Asset Library and the EditorSettings would also be able to store these AssetPackage files for remotely distributed and locally shared "packages" of addons.

Furthermore, I would want to be able to browse and configure these "packages" of addons during the project creation and addon browsing processes to provide more concentrated value and discoverability to users.

If a new-ish Godot user opens up the Project Manager to create a new project, they should be able to view a list of popular Packages that they can install alongside their project. Rather than needing to create their project, go to the AssetLib tab, and then browse through hundreds of addons and install interesting ones one-by-one, they could instead see a GUI of addons to select which are batch installed at the end of the process and which can be selected/de-selected in groups by selecting/de-selecting themed Packages.

Users should even be able to create their own AssetPackage resources, either for local use (to auto-install a collection of preferred addons) or to upload and manage for the community (like what Godot Next could do).

A "Package" could then be...

• Godot Next.
• A user-defined Favorites list of editor tools to share across all projects.
  • Perhaps we could add an AssetPackagae field in EditorSettings to accommodate this.
• A "framework" of addons tailored to specific fields:
  • A game genre such as 2D platformer or first-person shooter, etc.
  • A technology category such as Mobile Apps, Data Structures, AI, Particle Effects, etc.
• A team-organized collection of addons for specific tasks:
  • Producers get in-editor tools for task management, allocating team resources, etc.
  • Writers get in-editor tools for narrative dialogue editing, more visual scripting nodes, etc.
  • 3D artists get in-editor tools for voxel modeling or assets for meshes, textures, etc.

Note that one difference between an addon and a package is that addons simply declare a set of dependencies while packages can have both required and optional addons associated with them, as demonstrated in the final mockup below.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

The final UI I imagine for this would be like a blend of the VS Code extensions UI and the Visual Studio Installer.

The former contains a list of elements where selecting any one element displays an editor-rendered Markdown README + any other custom data (repo web URL, rating, whatever data we can safely store and use, assuming it doesn't violate GDPR).

For reference, here is the VS Code extensions image in #139:

.

The latter maintains a list of selected editor components and will mass add/remove components from the batch installation dialog as users add/remove packages of functionality from the installation. Individual components can also be browsed and added/removed as desired.

Here is the original Visual Studio Installer:

I'm imagining that we could setup our own packages-over-addons setup with a VS Code-like README renderer. Something along these lines:

And this would be something that can appear both in the AssetLib tab and as a popup when users are creating a new project. Packages would be pulled from the Godot Asset Library as well as from local user files.

Describe implementation detail for your proposal (in code), if possible:

1. I can publish individual addons (with just a single script even) with minimal effort (just pressing a few buttons).
   1. Editor can generate an addon for me (Remove "addon" versus "plugin" inconsistencies by adopting a single name for both #118).
   2. Editor can access third-party addon APIs for me (Enable plugins to integrate arbitrary 3rd-party data sources to the AssetLib tab #12).
   3. Editor can publish an addon for me to any supported API through a common interface (N/A).
      • Would require some plugin to enable users to interact with third-party APIs and publish to them. Things like this could even be part of an "Addon Creators" Package installable from the Project Manager.
      • Godot would need to be able to, at the very least, directly submit new asset version submissions to a selected remote online vendor (which defaults to the Asset Library, pending Asset versions instead of asset edits [Request For Comments]  godot-asset-library#143, and which gets other API support out-of-the-box with Enable plugins to integrate arbitrary 3rd-party data sources to the AssetLib tab #12 once their plugins are installed).
2. Users can easily browse addons, access their source repositories, and get their information.
   1. Editor AssetLib is redesigned to support rendering Markdown content (Add full Markdown support for use in browsing, creating, and editing projects and addons #139).
   2. Addons could expose direct documentation for included classes.
      1. Script annotations help here, but are not required (Annotations in GDScript godot#20318)
      2. Use script annotations and script reflection data (already exposed in 3.2) to generate XML documentation data. Then we can program the editor to auto-import that documentation data via a commonly defined directory structure. DocData would need to only integrate docs for script classes that are successfully registered. Any time script classes update, DocData would also need to be rebuilt. Start with a cached copy of the ClassDB-only DocData and then re-add all script class data as needed (Enable scripts to generate XML API documentation for the editor's GUI #177).
   3. See Add full Markdown support for use in browsing, creating, and editing projects and addons #139 for an example of what this could look like in the AssetLib editor tab.
3. Users can identify and automatically install all dependencies related to an addon.
   1. Addons would need a standardized, safe-to-copy-paste-install internal structure where Godot can validate whether a directory constitutes a valid addon because of its structure. Only when an addon directory has structured data can the editor apply installation logic to them universally, without humans having to manually check off which files are to be copied into a project (Establish convention for sharing libraries #62).
      • This might also involve the need for some kind of .gdignore file to filter out some files from bundling into an addon.
   • Problems with preventing "engine bloat" and the AssetLibrary godot#19486 discussion must be resolved.
   • godotengine/godot#19178 discussion must be resolved.
   • At the very least, we would need an agreed-upon dependency acquisition mechanism, regardless of whether it ends up being a full-blown management tool or just a "curl these URLs, kthxbai!"
4. Users can view collections of assets related to topics in which they are interested and can easily install/uninstall them en masse (this Issue).
   1. See mockup above.
   2. Packages would maintain a list of optional and required addons/sub-projects/whatever to be associated with them (will call them just "addons" for now).
   3. The GAL would need to be refactored to use a batch install process. In it, users would be able to select a set of addons to install (a list of checkboxes in the GUI).
      1. Every time the list of packages/addons is updated, rebuild the list.
      2. Allow users to view a flat list and search that list for addons directly (the regular GAL behavior).
      3. Allow users to view the checkboxes grouped into packages. If an addon is present in more than one package, that is fine (more about seeing what stuff is associated with a package overall). You still would only install that addon once.
      4. Potentially multithread the download and installation process?
      5. If someone clicks on an individual addon in the flat or grouped list, the currently active tab on the right should update to display that addon's information (README, CHANGELIST, name, other data).
      6. Users should be able to open new tabs in the addon viewer to quickly switch between cached versions of the data (without needing to re-fetch it).
      7. A loading icon should display between requesting a new addon's information and displaying it.
      8. The visualization of an addon's information should have no relevance to whether that addon is checked or unchecked in the flat/grouped list.

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

This enhancement is largely based on modifications to the Asset Library, the Editor's AssetLib tab, and introducing a new resource: AssetPackage. It also changes the Project Manager and is dependent on standardization changes in the addon ecosystem. It would revolutionize the accessibility and growth of addons, so yes, it would be used often.

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

Tons of changes to NOT script-accessible stuff. See above.