[Merged by Bors] - Plugins own their settings. Rework PluginGroup trait. by cart · Pull Request #6336 · bevyengine/bevy

cart · 2022-10-22T07:10:04Z

Objective

Fixes #5884 #2879
Alternative to #2988 #5885 #2886

"Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems:

If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead)
Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed.

(1) and (2) are especially problematic and confusing for the WindowDescriptor resource, but this is a general problem.

Solution

Immutable Plugin settings now live on each Plugin struct (ex: WindowPlugin). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the add_plugins_with api, as the add_plugins api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources.

Plugins are now configured like this:

app.add_plugin(AssetPlugin {
  watch_for_changes: true,
  ..default()
})

PluginGroups are now configured like this:

app.add_plugins(DefaultPlugins
  .set(AssetPlugin {
    watch_for_changes: true,
    ..default()
  })
)

This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons:

~~Plugin - setup resource #2988 doesn't solve (1)~~ Plugin - setup resource #2988 does solve (1) and will panic in that case. I was wrong!
This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it).
I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints.

Changelog

PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using plugin_group.set(SomePlugin {}), which enables overriding default plugin values.
WindowDescriptor plugin settings have been moved to WindowPlugin and AssetServerSettings have been moved to AssetPlugin
app.add_plugins_with has been replaced by using add_plugins with the builder pattern.

Migration Guide

The WindowDescriptor settings have been moved from a resource to WindowPlugin::window:

// Old (Bevy 0.8)
app
  .insert_resource(WindowDescriptor {
    width: 400.0,
    ..default()
  })
  .add_plugins(DefaultPlugins)

// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(WindowPlugin {
  window: WindowDescriptor {
    width: 400.0,
    ..default()
  },
  ..default()
}))

The AssetServerSettings resource has been removed in favor of direct AssetPlugin configuration:

// Old (Bevy 0.8)
app
  .insert_resource(AssetServerSettings {
    watch_for_changes: true,
    ..default()
  })
  .add_plugins(DefaultPlugins)

// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.set(AssetPlugin {
  watch_for_changes: true,
  ..default()
}))

add_plugins_with has been replaced by add_plugins in combination with the builder pattern:

// Old (Bevy 0.8)
app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>());

// New (Bevy 0.9)
app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>());

tests/window/minimising.rs

DGriffin91 · 2022-10-22T07:57:20Z

At first glance this makes a lot of sense to me. Does this mean that if a plugin author wants the users to be able access some of the immutable plugin settings as read only, it will need to insert them as separate resource? Probably not an issue, just curious.

crates/bevy_app/src/plugin_group.rs

harudagondi

Generally I like this change :) When I first look at plugins in bevy it was weird that a lot of them are empty structs, and its settings as a resource with a lot of weird edge cases. This is a step towards the correct direction.

harudagondi · 2022-10-22T09:54:36Z

crates/bevy_window/src/lib.rs

+impl Default for WindowPlugin {
+    fn default() -> Self {
+        WindowPlugin {
+            window: Default::default(),


Should we use default from bevy_utils?

In this position we haven't used it in the past (we currently only use it in struct update syntax). That would be a new pattern. Open to considering it, but its worth discussing elsewhere I think.

cart · 2022-10-22T18:03:32Z

At first glance this makes a lot of sense to me. Does this mean that if a plugin author wants the users to be able access some of the immutable plugin settings as read only, it will need to insert them as separate resource? Probably not an issue, just curious.

This is correct. In theory we could build a runtime interface into the App's Plugin structs themselves, but I think thats a conversation for another day. These types of settings are for "plugin constructor data" only. Anything that is needed at runtime should (probably) still be represented as a resource. The plugin settings disappearing is one of the reasons for this change in the first place, as these are values users shouldn't be relying on at runtime generally.

Co-authored-by: Torstein Grindvik <52322338+torsteingrindvik@users.noreply.github.com>

tim-blackbird

bevy_rapier already uses plugins like this, it's nice.

@cart, What are your thoughts on making Plugin::build consume the plugin?
edit: Cart talked about this on discord.

tim-blackbird · 2022-10-22T09:11:26Z

crates/bevy_window/src/lib.rs

+            window: Default::default(),
+            add_primary_window: true,


It makes sense now to remove add_primary_window and have window take an option.
This does make the most common usage a bit more annoying, but eh.

This does make the most common usage a bit more annoying, but eh.

Yeah this is why I went in this direction. This is already a slight reduction in UX for window configuration, as its now nested one level deep. Not having a primary window is a very uncommon practice (ex: less than one percent of people need it). I don't think degrading the common experience further is worth whatever "rust api pattern purity" we gain from using an option.

crates/bevy_internal/src/default_plugins.rs

crates/bevy_app/src/plugin_group.rs

Co-authored-by: ira <JustTheCoolDude@gmail.com>

cart · 2022-10-24T19:49:00Z

bors r+

# Objective Fixes #5884 #2879 Alternative to #2988 #5885 #2886 "Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems: 1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead) 2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed. (1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem. ## Solution Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources. Plugins are now configured like this: ```rust app.add_plugin(AssetPlugin { watch_for_changes: true, ..default() }) ``` PluginGroups are now configured like this: ```rust app.add_plugins(DefaultPlugins .set(AssetPlugin { watch_for_changes: true, ..default() }) ) ``` This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons: * ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong! * This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it). * I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints.

cart · 2022-10-24T19:49:32Z

bors r-

bors · 2022-10-24T19:49:33Z

Canceled.

cart · 2022-10-24T19:49:46Z

Cancelled because this needs a migration guide and changelog!

cart · 2022-10-24T20:02:31Z

bors r+

# Objective Fixes #5884 #2879 Alternative to #2988 #5885 #2886 "Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems: 1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead) 2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed. (1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem. ## Solution Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources. Plugins are now configured like this: ```rust app.add_plugin(AssetPlugin { watch_for_changes: true, ..default() }) ``` PluginGroups are now configured like this: ```rust app.add_plugins(DefaultPlugins .set(AssetPlugin { watch_for_changes: true, ..default() }) ) ``` This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons: * ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong! * This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it). * I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints. ## Changelog - PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values. - `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin` - `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern. ## Migration Guide The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`: ```rust // Old (Bevy 0.8) app .insert_resource(WindowDescriptor { width: 400.0, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(WindowPlugin { window: WindowDescriptor { width: 400.0, ..default() }, ..default() })) ``` The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(AssetServerSettings { watch_for_changes: true, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(AssetPlugin { watch_for_changes: true, ..default() })) ``` `add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern: ```rust // Old (Bevy 0.8) app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>()); // New (Bevy 0.9) app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>()); ```

bors · 2022-10-24T20:06:07Z

Build failed:

build-without-default-features (bevy)

crates/bevy_internal/src/default_plugins.rs

Co-authored-by: François <mockersf@gmail.com>

cart · 2022-10-24T20:52:03Z

bors r+

crates/bevy_internal/src/default_plugins.rs

Co-authored-by: François <mockersf@gmail.com>

bors · 2022-10-24T20:58:58Z

Canceled.

crates/bevy_internal/src/default_plugins.rs

Co-authored-by: François <mockersf@gmail.com>

mockersf · 2022-10-24T21:16:57Z

bors r+

# Objective Fixes #5884 #2879 Alternative to #2988 #5885 #2886 "Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems: 1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead) 2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed. (1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem. ## Solution Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources. Plugins are now configured like this: ```rust app.add_plugin(AssetPlugin { watch_for_changes: true, ..default() }) ``` PluginGroups are now configured like this: ```rust app.add_plugins(DefaultPlugins .set(AssetPlugin { watch_for_changes: true, ..default() }) ) ``` This is an alternative to #2988, which is similar. But I personally prefer this solution for a couple of reasons: * ~~#2988 doesn't solve (1)~~ #2988 does solve (1) and will panic in that case. I was wrong! * This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it). * I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints. ## Changelog - PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values. - `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin` - `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern. ## Migration Guide The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`: ```rust // Old (Bevy 0.8) app .insert_resource(WindowDescriptor { width: 400.0, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(WindowPlugin { window: WindowDescriptor { width: 400.0, ..default() }, ..default() })) ``` The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(AssetServerSettings { watch_for_changes: true, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(AssetPlugin { watch_for_changes: true, ..default() })) ``` `add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern: ```rust // Old (Bevy 0.8) app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>()); // New (Bevy 0.9) app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>()); ```

bors · 2022-10-24T21:34:41Z

Pull request successfully merged into main.

Build succeeded:

# Objective - Build on #6336 for more plugin configurations ## Solution - `LogSettings`, `ImageSettings` and `DefaultTaskPoolOptions` are now plugins settings rather than resources --- ## Changelog - `LogSettings` plugin settings have been move to `LogPlugin`, `ImageSettings` to `ImagePlugin` and `DefaultTaskPoolOptions` to `CorePlugin` ## Migration Guide The `LogSettings` settings have been moved from a resource to `LogPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(LogSettings { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(LogPlugin { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), })) ``` The `ImageSettings` settings have been moved from a resource to `ImagePlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(ImageSettings::default_nearest()) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(ImagePlugin::default_nearest())) ``` The `DefaultTaskPoolOptions` settings have been moved from a resource to `CorePlugin::task_pool_options`: ```rust // Old (Bevy 0.8) app .insert_resource(DefaultTaskPoolOptions::with_num_threads(4)) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(CorePlugin { task_pool_options: TaskPoolOptions::with_num_threads(4), })) ```

# Objective Fixes bevyengine#5884 bevyengine#2879 Alternative to bevyengine#2988 bevyengine#5885 bevyengine#2886 "Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems: 1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead) 2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed. (1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem. ## Solution Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources. Plugins are now configured like this: ```rust app.add_plugin(AssetPlugin { watch_for_changes: true, ..default() }) ``` PluginGroups are now configured like this: ```rust app.add_plugins(DefaultPlugins .set(AssetPlugin { watch_for_changes: true, ..default() }) ) ``` This is an alternative to bevyengine#2988, which is similar. But I personally prefer this solution for a couple of reasons: * ~~bevyengine#2988 doesn't solve (1)~~ bevyengine#2988 does solve (1) and will panic in that case. I was wrong! * This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it). * I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints. ## Changelog - PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values. - `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin` - `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern. ## Migration Guide The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`: ```rust // Old (Bevy 0.8) app .insert_resource(WindowDescriptor { width: 400.0, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(WindowPlugin { window: WindowDescriptor { width: 400.0, ..default() }, ..default() })) ``` The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(AssetServerSettings { watch_for_changes: true, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(AssetPlugin { watch_for_changes: true, ..default() })) ``` `add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern: ```rust // Old (Bevy 0.8) app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>()); // New (Bevy 0.9) app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>()); ```

# Objective - Build on bevyengine#6336 for more plugin configurations ## Solution - `LogSettings`, `ImageSettings` and `DefaultTaskPoolOptions` are now plugins settings rather than resources --- ## Changelog - `LogSettings` plugin settings have been move to `LogPlugin`, `ImageSettings` to `ImagePlugin` and `DefaultTaskPoolOptions` to `CorePlugin` ## Migration Guide The `LogSettings` settings have been moved from a resource to `LogPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(LogSettings { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(LogPlugin { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), })) ``` The `ImageSettings` settings have been moved from a resource to `ImagePlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(ImageSettings::default_nearest()) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(ImagePlugin::default_nearest())) ``` The `DefaultTaskPoolOptions` settings have been moved from a resource to `CorePlugin::task_pool_options`: ```rust // Old (Bevy 0.8) app .insert_resource(DefaultTaskPoolOptions::with_num_threads(4)) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(CorePlugin { task_pool_options: TaskPoolOptions::with_num_threads(4), })) ```

# Objective Fixes bevyengine#5884 bevyengine#2879 Alternative to bevyengine#2988 bevyengine#5885 bevyengine#2886 "Immutable" Plugin settings are currently represented as normal ECS resources, which are read as part of plugin init. This presents a number of problems: 1. If a user inserts the plugin settings resource after the plugin is initialized, it will be silently ignored (and use the defaults instead) 2. Users can modify the plugin settings resource after the plugin has been initialized. This creates a false sense of control over settings that can no longer be changed. (1) and (2) are especially problematic and confusing for the `WindowDescriptor` resource, but this is a general problem. ## Solution Immutable Plugin settings now live on each Plugin struct (ex: `WindowPlugin`). PluginGroups have been reworked to support overriding plugin values. This also removes the need for the `add_plugins_with` api, as the `add_plugins` api can use the builder pattern directly. Settings that can be used at runtime continue to be represented as ECS resources. Plugins are now configured like this: ```rust app.add_plugin(AssetPlugin { watch_for_changes: true, ..default() }) ``` PluginGroups are now configured like this: ```rust app.add_plugins(DefaultPlugins .set(AssetPlugin { watch_for_changes: true, ..default() }) ) ``` This is an alternative to bevyengine#2988, which is similar. But I personally prefer this solution for a couple of reasons: * ~~bevyengine#2988 doesn't solve (1)~~ bevyengine#2988 does solve (1) and will panic in that case. I was wrong! * This PR directly ties plugin settings to Plugin types in a 1:1 relationship, rather than a loose "setup resource" <-> plugin coupling (where the setup resource is consumed by the first plugin that uses it). * I'm not a huge fan of overloading the ECS resource concept and implementation for something that has very different use cases and constraints. ## Changelog - PluginGroups can now be configured directly using the builder pattern. Individual plugin values can be overridden by using `plugin_group.set(SomePlugin {})`, which enables overriding default plugin values. - `WindowDescriptor` plugin settings have been moved to `WindowPlugin` and `AssetServerSettings` have been moved to `AssetPlugin` - `app.add_plugins_with` has been replaced by using `add_plugins` with the builder pattern. ## Migration Guide The `WindowDescriptor` settings have been moved from a resource to `WindowPlugin::window`: ```rust // Old (Bevy 0.8) app .insert_resource(WindowDescriptor { width: 400.0, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(WindowPlugin { window: WindowDescriptor { width: 400.0, ..default() }, ..default() })) ``` The `AssetServerSettings` resource has been removed in favor of direct `AssetPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(AssetServerSettings { watch_for_changes: true, ..default() }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(AssetPlugin { watch_for_changes: true, ..default() })) ``` `add_plugins_with` has been replaced by `add_plugins` in combination with the builder pattern: ```rust // Old (Bevy 0.8) app.add_plugins_with(DefaultPlugins, |group| group.disable::<AssetPlugin>()); // New (Bevy 0.9) app.add_plugins(DefaultPlugins.build().disable::<AssetPlugin>()); ```

# Objective - Build on bevyengine#6336 for more plugin configurations ## Solution - `LogSettings`, `ImageSettings` and `DefaultTaskPoolOptions` are now plugins settings rather than resources --- ## Changelog - `LogSettings` plugin settings have been move to `LogPlugin`, `ImageSettings` to `ImagePlugin` and `DefaultTaskPoolOptions` to `CorePlugin` ## Migration Guide The `LogSettings` settings have been moved from a resource to `LogPlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(LogSettings { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), }) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(LogPlugin { level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace".to_string(), })) ``` The `ImageSettings` settings have been moved from a resource to `ImagePlugin` configuration: ```rust // Old (Bevy 0.8) app .insert_resource(ImageSettings::default_nearest()) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(ImagePlugin::default_nearest())) ``` The `DefaultTaskPoolOptions` settings have been moved from a resource to `CorePlugin::task_pool_options`: ```rust // Old (Bevy 0.8) app .insert_resource(DefaultTaskPoolOptions::with_num_threads(4)) .add_plugins(DefaultPlugins) // New (Bevy 0.9) app.add_plugins(DefaultPlugins.set(CorePlugin { task_pool_options: TaskPoolOptions::with_num_threads(4), })) ```

cart added 2 commits October 21, 2022 23:25

Plugins own their settings. Rework PluginGroup trait

b814279

AssetPlugin settings

ff0fb25

cart added C-Usability A targeted quality-of-life change that makes Bevy easier to use A-App Bevy apps and plugins M-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide X-Needs-SME This type of work requires an SME to approve it. labels Oct 22, 2022

DGriffin91 reviewed Oct 22, 2022

View reviewed changes

tests/window/minimising.rs Outdated Show resolved Hide resolved

torsteingrindvik reviewed Oct 22, 2022

View reviewed changes

crates/bevy_app/src/plugin_group.rs Outdated Show resolved Hide resolved

harudagondi reviewed Oct 22, 2022

View reviewed changes

cart and others added 3 commits October 22, 2022 11:06

Update crates/bevy_app/src/plugin_group.rs

d2afbea

Co-authored-by: Torstein Grindvik <52322338+torsteingrindvik@users.noreply.github.com>

remove unnecessary .build() from example

77fcfbe

fix docs and clippy

ea17700

tim-blackbird reviewed Oct 22, 2022

View reviewed changes

mockersf added this to the Bevy 0.9 milestone Oct 23, 2022

mockersf approved these changes Oct 23, 2022

View reviewed changes

harudagondi approved these changes Oct 23, 2022

View reviewed changes

mockersf added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Oct 23, 2022

Update crates/bevy_app/src/plugin_group.rs

6623ad2

Co-authored-by: ira <JustTheCoolDude@gmail.com>

mockersf reviewed Oct 24, 2022

View reviewed changes

crates/bevy_internal/src/default_plugins.rs Outdated Show resolved Hide resolved

Update crates/bevy_internal/src/default_plugins.rs

54d8628

Co-authored-by: François <mockersf@gmail.com>

mockersf reviewed Oct 24, 2022

View reviewed changes

crates/bevy_internal/src/default_plugins.rs Outdated Show resolved Hide resolved

Update crates/bevy_internal/src/default_plugins.rs

7e269e4

Co-authored-by: François <mockersf@gmail.com>

mockersf reviewed Oct 24, 2022

View reviewed changes

crates/bevy_internal/src/default_plugins.rs Outdated Show resolved Hide resolved

Update crates/bevy_internal/src/default_plugins.rs

653a6df

Co-authored-by: François <mockersf@gmail.com>

bors bot changed the title ~~Plugins own their settings. Rework PluginGroup trait.~~ [Merged by Bors] - Plugins own their settings. Rework PluginGroup trait. Oct 24, 2022

bors bot closed this Oct 24, 2022

mockersf added the hacktoberfest-accepted label Oct 24, 2022

cart mentioned this pull request Oct 24, 2022

Plugin - setup resource #2988

Closed

mockersf mentioned this pull request Oct 24, 2022

[Merged by Bors] - Use plugin setup for resource only used at setup time #6360

Closed

This was referenced Nov 1, 2022

WindowDescriptor has no effect if resource is inserted after .add_plugins(DefaultPlugins) is called during app construction #4386

Closed

Can't change title at runtime. #2879

Closed

mockersf mentioned this pull request Nov 8, 2022

[Merged by Bors] - Migration guide 0.9 bevyengine/bevy-website#470

Closed

bzm3r mentioned this pull request Dec 22, 2022

Use bevy's suggested pattern for configuring plugins to configure the GenerationPlugin Leafwing-Studios/Emergence#124

Closed

paul-hansen mentioned this pull request Jan 4, 2023

Hot reload needs updated for Bevy 0.9 TimJentzsch/cargo-bavy#22

Closed

cart mentioned this pull request May 10, 2024

Add simple preferences API #13312

Closed

Uh oh!

Conversation

cart commented Oct 22, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Changelog

Migration Guide

Uh oh!

Uh oh!

DGriffin91 commented Oct 22, 2022

Uh oh!

Uh oh!

harudagondi left a comment

Choose a reason for hiding this comment

Uh oh!

harudagondi Oct 22, 2022

Choose a reason for hiding this comment

Uh oh!

cart Oct 22, 2022

Choose a reason for hiding this comment

Uh oh!

cart commented Oct 22, 2022

Uh oh!

tim-blackbird left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tim-blackbird Oct 22, 2022

Choose a reason for hiding this comment

Uh oh!

cart Oct 24, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

cart commented Oct 24, 2022

Uh oh!

cart commented Oct 24, 2022

Uh oh!

bors bot commented Oct 24, 2022

Uh oh!

cart commented Oct 24, 2022

Uh oh!

cart commented Oct 24, 2022

Uh oh!

bors bot commented Oct 24, 2022

Uh oh!

Uh oh!

cart commented Oct 24, 2022

Uh oh!

Uh oh!

bors bot commented Oct 24, 2022

Uh oh!

Uh oh!

mockersf commented Oct 24, 2022

Uh oh!

bors bot commented Oct 24, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

cart commented Oct 22, 2022 •

edited

Loading

tim-blackbird left a comment •

edited

Loading