-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Unique plugin #6411
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and simple, very useful. Definitely agree with the decision to make plugins unique by default.
I'd like:
- Docs about the behavior of generic plugins.
- A should_panic test for duplicate plugins.
- A test that allowing duplicates works.
- A test that adding generic plugins with different type parameters works.
Looks like #3988 has tests, so steal those :p
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some docs for you :) I won't block on them, but do think they should be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Some minor changes regarding startup performance and usability.
bors r+ |
# Objective - Make it impossible to add a plugin twice - This is going to be more a risk for plugins with configurations, to avoid things like `App::new().add_plugins(DefaultPlugins).add_plugin(ImagePlugin::default_nearest())` ## Solution - Panic when a plugin is added twice - It's still possible to mark a plugin as not unique by overriding `is_unique` - ~~Simpler version of~~ #3988 (not simpler anymore because of how `PluginGroupBuilder` implements `PluginGroup`)
This seems to have broken my latest builds: Update:
Perhaps there should be a followup PR to make it so that you can't name two different plugins the same thing? |
I saw you mention this in the discord and thought that was odd.. Like, if the code is using the type name to identify uniqueness, I would expect it would be the fully qualified name so that you wouldn't get collisions across crates. It looks like this PR uses the Plugin trait's Additionally, @mockersf (and maybe @alice-i-cecile?):
again, just saw this and thought 🤔 and wanted to make sure this was all OK |
Yeah, I think that we should update those docs to reflect its use in this feature. I'm fine using std::any::type_name for this though, especially since there's multiple escape hatches. |
I don't like the thought of Bevy or third party crates adding a new Plugin(even a private one!) breaking user code because the name overlaps. How about identifying unique plugins by TypeId, or perhaps a combination of TypeId and the name? |
@devil-ira Based on the documentation of std::any::type_name, I don't think this happens. It looks like it outputs the fully qualified name (for now :eyes:). Your concern is exactly why I brought it up because @LarsDu said this happened when they had a plugin named ScenePlugin in their user code. I think we'll want to wait until they confirm that's actually what happened. |
Bevy's own |
# Objective - Make it impossible to add a plugin twice - This is going to be more a risk for plugins with configurations, to avoid things like `App::new().add_plugins(DefaultPlugins).add_plugin(ImagePlugin::default_nearest())` ## Solution - Panic when a plugin is added twice - It's still possible to mark a plugin as not unique by overriding `is_unique` - ~~Simpler version of~~ bevyengine#3988 (not simpler anymore because of how `PluginGroupBuilder` implements `PluginGroup`)
Objective
App::new().add_plugins(DefaultPlugins).add_plugin(ImagePlugin::default_nearest())
Solution
is_unique
Simpler version ofcan only add a plugin once #3988 (not simpler anymore because of howPluginGroupBuilder
implementsPluginGroup
)