[QoL] Multiple or no config dropdown for plugins

[Krarilotus]

It would be great for certain plugins, if we had the option to preconfigure multiple configurations or be even able to just load them as files.
Currently we have two plugins for this, say any of the AI plugins, they have a normal version, containing just files and one with just the configuration, named 'applied'
-> This clutters up the list of plugins and also confuses users

It would be better if we had the option to define multiple configurations for a plugin, and even have the option to load a plugin without its configuration. I would also be neat if the plugin creator could then define a default configuration to be loaded and how the other options are called and if they are available. Most of the time it comes down to loading plugins just for their files to use them in other plugins and dropping the configuration.

I would propose the option of another dropdown just like with the version number of the plugin. I would say picking a configuration for the plugin can come after its activation, but ofc. we could also make it save the user selected configuration per plugin within the overall UCP / GUI status file which we already need for launch parameters to be saved.

[gynt]

This does not fit in the current dependency logic. Extensions depend on other extensions, activating a dependency extension activates its configuration.

Allowing multiple configurations per extension would also need clarity on the following:

• An extension should be able to depend on a specific configuration from another extension.
• Can an extension define different dependencies for different configurations they supply?
• Can a user activate multiple configurations from the same extension?

If clutter is the problem, I suggest we remove clutter as much as possible with #236 and #237 and not complicate the dependency graph.

[Krarilotus]

If clutter is the problem, I suggest we remove clutter as much as possible with #236 and #237 and not complicate the dependency graph.
So des that mean, it would require like say 10 extensions for making configurations for just one extension that has actual files in it?
The clutter here is not the clutter on the UCP-GUI side, but the clutter starts, when people have to create tens and hundreds of repos for just one mod they want to provide with some preconfigured options on how to use it

I would argue, it makes more sense, to have this clutter removed on the backend, than adding it to the frontend and just filtering it out.

Hence my original suggestions stands with its implications!

-> It would need restructuring of the config. I would tho: Say that if a dependency doesn't specify a certain configuration or specify explictly 'no configuration' in their dependency, then it should use the default configuration of a plugin:

That way we can keep all existing logic, and just add onto it, by giving the dependency another property, that should work in a yaml, if i understand it correctly?

[gynt]

Currently it is like this:

dependencies:
  A: ">= 1.0.0"

I think you want:

dependencies:
- extension: A
  version: ">= 1.0.0"
  configuration: "default"

---

We need to tackle these three things:

An extension should be able to depend on a specific configuration from another extension.
Can an extension define different dependencies for different configurations they supply?
Can a user activate multiple configurations from the same extension?

Currently, what you propose only tackles the easy situation: when no configuration is asked for, it defaults to a default configuration.

Situation A
Let's start with this one, given the list of extensions below in order of high priority to low priority. In this situation, extension B depends on A's config1, and extension C depends on A's config2 configuration, they both depend on D's config1 configuration. How should this be resolved?

- name: C
  dependencies:
  - extension: A
    version: ">= 1.0.0"
    configuration: "config2"
  - extension: D
    version: ">= 1.0.0"
    configuration: "config1"
- name: B
  dependencies:
  - extension: A
    version: ">= 1.0.0"
    configuration: "config1"
  - extension: D
    version: ">= 1.0.0"
    configuration: "config1"
- name: D

Options

1. The dependency of B on A is ignored in favor of the dependency of C on A (A's config1 configuration would be dropped, i.e. A would be set to load config2 only).
2. The configuration of config1 and config2 of extension A are merged if they are mergeable (i.e. required values for configuration settings do not conflict). If not mergeable, having C in the list together with B is not allowed.
3. Do not allow this, only one configuration of A can be depended on. Having C in the list together with B is not allowed.

GUI
In general, what name should be displayed in the GUI for a config? These configs should be descriptive or else people don't know what to expect, but they should be short otherwise they don't fit in the GUI.

If option 1 or 3 is preferred, the GUI can be relatively simple: extension A would display which of their configs are currently selected. This displayed config name can change if extensions are activated that make a different dependency-demand.
If option 2 is preferred, the GUI cannot be simple: both config1 and config2 are active in some fashion. At best, the extension A can display "(merged)" or "(custom)" as the currently active configuration, but that isn't very descriptive to the end user.

Situation B
The same as situation A, except extension A released a version 1.1.0 with a new config1 with some new required values that conflict with config2. What should happen? If option 2 was chosen in situation A, this can mean that the same config people had (e.g. the currently presented one) doesn't work anymore.

Options

1. Do not allow configurations to change over time. Thus, extension A cannot update a new config1, but rather it should create a config3. This makes the list of configurations it has quite long and descriptive names loose their descriptiveness if modifications are minor.
2. Something else?