Different plugin groups to support different use cases (diverse-defaults for short)

[colepoirier]

Rendered

There are many different categories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. This RFC is a proposal to consider making such a change.

[alice-i-cecile]

First round of feedback and clarity suggestions :)

[alice-i-cecile]

It's not clear how exactly this interacts with the "use case" plugins groups above 🤔 I agree that we want both, but they seem mostly orthogonal.

[colepoirier]

I think @mockersf proposal enables use to meld the two in a sensible way!

[alice-i-cecile]

I think it would be helpful hear to identify "axes of variation"; ways that each of the use cases commonly vary, so we can think about how to structure them.

[colepoirier]

I very much agree, though I don't know how to flesh this out.

[alice-i-cecile]

This needs a note in implementation details on what we should include to get this working.

[colepoirier]

What exactly would we need to include to get this working? I don't understand the details of the bevy DefaultPlugins code I guess.

[colepoirier]

Also would probably prefer to just migrate my initial proposal to the one @mockersf suggested which I think addresses the problem area even better! :)

[alice-i-cecile]

The bigger problem is "I don't know how to make a terminal game in Bevy 0.6" at all. There were a few ecosystem crates, but they're no longer up to date.

[mockersf]

Instead of having different PluginGroups, I think this would be better suited for compilation features:

• they reduce compile time
• they guarantee that the code won't be present
• they are the only way to have different const values
• they work well with compilation target, which is what you call "divergent platform"
• they are already present and mostly usable that way in Bevy

For example, for a 2d game that won't use UI but will still display text in the 2d world, I use only those features: "bevy_core_pipeline", "bevy_sprite", "bevy_winit", "bevy_render", "bevy_text", "png".

Features are probably not documented enough and not really friendly, Bevy could add meta features to group them into logical groups like you describe here.

[colepoirier]

Instead of having different PluginGroups, I think this would be better suited for compilation features:

* they reduce compile time

* they guarantee that the code won't be present

* they are the only way to have different `const` values

* they work well with compilation target, which is what you call "divergent platform"

* they are already present and mostly usable that way in Bevy

For example, for a 2d game that won't use UI but will still display text in the 2d world, I use only those features: "bevy_core_pipeline", "bevy_sprite", "bevy_winit", "bevy_render", "bevy_text", "png".

Features are probably not documented enough and not really friendly, Bevy could add meta features to group them into logical groups like you describe here.

That's a really nice idea @mockersf and I think this solves the problem I am seeking to address in an even nicer way with the additional benefits you outlined!! :) 💯

[alice-i-cecile]

I think you should discuss the pros and cons of plugin groups vs. feature groups in this section.

[colepoirier]

How would you define FeatureGroups?

[alice-i-cecile]

Rust features can enable other features, allowing users to toggle them on and off as needed. We can also

See: https://doc.rust-lang.org/cargo/reference/features.html for a basic introduction.
https://docs.rs/cfg_feature_groups/latest/cfg_feature_groups/ or the like may be helpful to improve ergonomics.