Allow tuples in add_plugins.

[geieredgar]

Objective

This is just a small idea of mine about a possible unified API.
(see #7687 (comment))

• Helps Add support for adding custom log layers #7682

Solution

(see #7687 (comment))
Add a single add method to which a Plugin, a PluginGroup or a FnOnce(&mut App) can be passed. Plugins that need resources to be inserted before they can be built (because they don't want to use an ugly hack like Arc<Mutex<Option<T>>>) can now provide an constructor that returns an FnOnce which takes care of that (see logger_example).

Pros:

• Can pass tuples to add_plugins.
• Added Flexibility: Application code can easily and ergonomically split up setup code into functions that take an &mut App parameter.
• Users don't have to worry about the difference of add_plugin vs add_plugins
• Shorter to write: app.add_plugins(DefaultPlugins) vs app.add(DefaultPlugins). The type names already make clear that Plugins are added.

Cons:

• Redundancy on the API level. This can be solved by removing add_plugin and add_plugins or reducing their visibility.
• Probably harder to write docs.

[alice-i-cecile]

Hmm. Very interesting, but I think ultimately a regression. It's a lot harder for users to understand exactly what they need to pass in, or what existing code is doing.

[geieredgar]

Okay, I have changed the code to make add_plugin and add_plugins work similar to add_system / add_systems.

add_plugin now accepts an argument that implements the sealed IntoPlugin trait, which is implemented for Plugin and FnOnce(&mut App) -> Plugin.
add_plugins now accepts an argument that implements the sealed IntoPluginGroup trait, which is implemented for PluginGroup, FnOnce(&mut App) -> PluginGroup and tuples containing Plugins PluginGroups and FnOnces.

This does not any longer fix the problem in #7631, but would still help implementing #7682.

[alice-i-cecile]

Definitely like that better!

[geieredgar]

I have moved the traits into their corresponding module and added additional tests and documentations for the traits.

[geieredgar]

Superseded by #8097.

[johanhelsing]

As far as i understand, the other pr will not help with the ownership issues i ran into in #7682, though... Is there another solution for that?

[geieredgar]

I didn't include it because it felt somewhat hacky to solve the problem in this way, I believe the better approach would be to change Plugin::build to take self instead of &self. I will open an PR for that.

[geieredgar]

Making Plugin::build take self is unfortunately not possible without a lot of refactoring / breaking existing users, because of App::get_added_plugins. Therefore I've decided to only change Plugin::build to take &mut self, which would at least allow us to get rid of the Arc<Mutex<_>> part. PR: #8101.

[johanhelsing]

Alright, thanks for looking into it :) Sounds like a decent compromise.