Add subgroup

[BD103]

Objective

Sometimes a PluginGroup requires another PluginGroup, like DefaultPlugins. The previous solution to this was:

use bevy::prelude::*;
use bevy::app::PluginGroupBuilder;

struct GamePlugins;

impl PluginGroup for GamePlugins {
    fn build(&mut self, group: &mut PluginGroupBuilder) {
        DefaultPlugins.build(group);

        // Add more plugins here...
    }
}

This feels backwards, even though it is correct.

Solution

Add a quality-of-life function that merges another group into the current one.

use bevy::prelude::*;
use bevy::app::PluginGroupBuilder;

struct GamePlugins;

impl PluginGroup for GamePlugins {
    fn build(&mut self, group: &mut PluginGroupBuilder) {
        group.add_subgroup(DefaultPlugins);

        // Add more plugins here...
    }
}

---

Changelog

Added PlugingGroupBuilder::add_subgroup().

Reasoning

My game is structured in a set of plugins. All you need to do is call App::new().add_plugins(GamePlugins).run(). This ensures that all the required plugins are registered. If main.rs has to also register DefaultPlugins, but doesn't, then my game would break. To fix this, I attach the default plugins as seen in the first example. I was dissatisfied with how that broke the flow of the code, so I wrote this function to fix it.

[BD103]

I've fixed the doc example, though now it simulates DefaultPlugins instead of actually using them. The build is failing because of a ron deprecation, but #5021 should fix that.

If requested, I can add this to the plugin group example.

Also, please look over the unit test and make sure I did it correctly. This is my first time contributing to Bevy, so I may have done something wrong.

[alice-i-cecile]

I like this API; I think that this helps make the logic clearer when working with plugin groups.

Great work with the doc tests, and the PR writeup did a great job motivating this change.

I think this would be worth adding to the plugin group example, but I won't block on it.

[BD103]

Thanks for the feedback! I'll look into adding an example.

[BD103]

I have updated the example to show using add_subgroup. As long as that looks good, this PR is ready to merge.

[alice-i-cecile]

Example looks good. This needs one more review from the community before I can merge it; perhaps ask in #engine-dev on Discord?

[BD103]

I'm sorry, but I don't use Discord. Do you have any other suggestions?

[alice-i-cecile]

I'll ask for you then :) No worries!

[BD103]

Thanks! :D

[james7132]

This current implementation rebuilds the entire plugin group it depends on. If done from multiple plugin groups declaring them as dependencies, you'll reregister everything under that dependency N times. This is clearly not desirable in the general case. We need explicit deduplication before this should be considered.

[alice-i-cecile]

Blocked on #69 then.

[BD103]

It's been a while since there's been activity here. Should I close the PR or leave it open?

[alice-i-cecile]

Let's close this out per the comment from James; we can always reopen in the future.

[BD103]

Ok, I won't delete my fork though until this gets resolved.