Move aabb gizmos to `bevy_dev_tools` #12354

chompaa · 2024-03-06T23:48:21Z

Objective

Done as part of #12351.

Solution

Moved the aabb module out of bevy_gizmos and into bevy_dev_tools.

Migration Guide

Aabb gizmos are no longer used through GizmoPlugin. You must enable the bevy_dev_tools feature instead.

github-actions · 2024-03-06T23:56:53Z

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

alice-i-cecile · 2024-03-06T23:57:29Z

crates/bevy_dev_tools/src/lib.rs

@@ -1,10 +1,13 @@
 //! This crate provides additional utilities for the [Bevy game engine](https://bevyengine.org),
 //! focused on improving developer experience.

-use bevy_app::prelude::*;
+pub mod aabb;


I think this probably makes mores sense as aabb_gizmo or something here :)

pablo-lua

Good, but I was thinking in the future: Should things added to the tools be all behind feature flags so the user can easily disable then? Or maybe we should do the DevToolPlugin into a PluginGroup to make it a easy thing to do? 🤔

chompaa · 2024-03-07T00:19:06Z

Unless I'm missing something, I think this is blocked by the fact that bevy_render depends on bevy_dev_tools and e.g. bevy_gizmos depends on bevy_render.

pablo-lua · 2024-03-07T00:22:45Z

I think we are missing imports on cargo, we might want to add to the imports bevy_render and bevy_color (and other needed crates)

chompaa · 2024-03-07T00:24:35Z

I think we are missing imports on cargo, we might want to add to the imports bevy_render and bevy_color (and other libs crates)

Adding bevy_render causes a circular dependency since bevy_render has bevy_dev_tools in its dependencies. A similar issue happens when adding bevy_gizmos, since it depends on bevy_render.

pablo-lua · 2024-03-07T00:35:12Z

bevy_render has bevy_dev_tools

Understood. Looks like we are using it in render to add tests when dev_tools feature is on, and even use some types from it, what a pain

github-actions · 2024-03-07T03:14:29Z

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

mgi388 · 2024-03-07T03:29:47Z

In the spirit of Cart's comment on the main bevy_dev_tools PR, why is bevy_dev_tools a better place for this than bevy_gizmos? There's probably more context in the main PR and Discord, but it seems like at very least this PR and #12351 could do with a strong written reason that it's a good idea.

As an example for why this jumps out to me as not clear cut: Couldn't you build a game that has AabbGizmoPlugin shipped to end users i.e. the plugin is not just for "dev tools"? Maybe it's enough to say that gizmos are 99% of the time only for devs and not end users, just a thought. In light of Cart's comment, and looking at the current list in #12351, could the same argument hold for a bunch of camera stuff? i.e. you could ship them to end users, and not just use them as "dev tools". Maybe the 1% here isn't enough to justify my thinking, and if so, all good!

I'd say you all know what you're doing and this is a good idea :), but it could be useful to document strong reason this is a good move in separate PRs that do the change, for posterity, etc. It would also help make sure each PR is directly thinking back to Cart's comment to make sure it's not a grab bag 🤔

alice-i-cecile · 2024-03-07T04:01:48Z

Great question! My stance on "what is bevy_dev_tools":

I'd like a unified set of tools that can be used to ease the development of Bevy games, primarily by displaying information about the state of the app.
These tools should be easy to discover.
These tools should have a unified style and use shared idioms and code.
These tools should be able to be toggled on and off by end users in a number of convenient ways using a consistent pattern (e.g. editor command palette, dev console, and so on).

The fact that users could use these tools in a final product doesn't negate the fact that they're primarily going to be used for development: there's nothing stopping you from enabling dev tools in your final build but only turning on the key features you need :)

mgi388 · 2024-03-07T04:25:37Z

I guess in my hypothetical example, if the real game needs the Aabb gizmo for an end-user mechanic (again, hypothetical, maybe too contrived), then the game dev can still use the AabbGizmoPlugin: it's just that it comes off bevy_dev_tools, not bevy_gizmos. And if solving for the 99% case makes more sense for it to be in the first one, not the second, then I suppose that's fine isn't it, and there's no problem here.

Out of interest, is there any reason that stuff has to live inside bevy_dev_tools and bevy_dev_tools can't just be a place for all the dev tools to come together in a unified fashion, toggleable, etc.? I note the first 3 items in your "stance" above seem to be to do with the goal of creating a crate to serve a specific purpose (dev tools) rather than gluing stuff together from around the engine. Perhaps "gluing stuff together" (as I'm devil's advocating for) has just historically not worked for Bevy, and then this circles back to why this whole move/push is happening.

afonsolage · 2024-03-07T06:06:14Z

Isn't bevy_dev_tools the new bevy_utils? I mean, the whole bevy is a dev tool. I'm worried we are increasing the scope of bevy_dev_tools to later on have to reduce its scope, like bevy_utils right now.

I would prefer a bevy_gizmos crate rather than moving to something which is generic, like bevy_dev_tools.

pablo-lua · 2024-03-07T10:26:10Z

Well, the initial proposal was to have a canonical place to put the tools that we we'll for sure do in our way to make the editor happen. I think thebevy_dev_tools meaning is to be used internally by bevy_editor in the future. At the same time, there is some things that are placed here and there in the engine and could use of a better place to put them, like Aabb gizmos itself, which is a dev tool for sure (which doesn't block you from shipping if you really want, of course). This aabb thing doesn't change anything in gizmos: it's just a tool, meaning to be used as it, and IMO aabb gizmos and light gizmos are flashy because they are the only ones that add plugins to the App instead of methods to the gizmos: ArrowBuilder is a example here that can explain how them are different.

matiqo15 · 2024-03-07T18:33:56Z

crates/bevy_dev_tools/src/lib.rs

@@ -35,10 +38,12 @@ pub mod ci_testing;
 pub struct DevToolsPlugin;

 impl Plugin for DevToolsPlugin {
-    fn build(&self, _app: &mut App) {
+    fn build(&self, app: &mut App) {
+        app.add_plugins(AabbGizmoPlugin);


I think, for now, we should hide it behind a feature and change it later when we create some other abstraction for toggling specific tools

I agree. We have to create this abstraction soon, though, the amount of created features can be very high if we don't handle with care.

I think we can do DevToolsPlugin into a PluginGroup, to make it easy disable and enable things, but I'm not sure how this will play with DefaultPlugins though

I've thought about it too, but wouldn't it then be impossible to change dev tools during runtime? I also thought about making a config as a resource but there might be a better way

I don't think there is a way at disabling this at runtime right now, at least not in the way we are currently doing
we add plugins to the app after all, is there a way to currently disabling a plugin, adding a plugin, or even adding systems at runtime right now? If we want, we can at least make it into a group now and mitigate the effects I guess, at least while we don't have the runtime tool manager

Yes we can't add/remove plugins at runtime (see #11083), but maybe we could achieve something without plugins? I think we should create an issue regarding this to decide which direction we want to go for now

chompaa · 2024-03-11T22:31:01Z

Once some dev tool abstraction is added (i.e. #12427) I'll update this PR.

Move Aabb gizmos to bevy_dev_tools

9de5b0b

chompaa changed the title ~~Move Aabb gizmos to bevy_dev_tools~~ Move aabb gizmos to bevy_dev_tools Mar 6, 2024

alice-i-cecile added C-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide A-Gizmos Visual editor and debug gizmos A-Dev-Tools Tools used to debug Bevy applications. labels Mar 6, 2024

alice-i-cecile reviewed Mar 6, 2024

View reviewed changes

alice-i-cecile mentioned this pull request Mar 6, 2024

Move the already existent tools into bevy_dev_tools and creation of new ones #12351

Open

9 tasks

chompaa added 3 commits March 6, 2024 23:59

Fix wrong variable name

fa72006

Rename aabb -> aabb_gizmo

4716a5d

Fix module name

0c2fa0e

pablo-lua approved these changes Mar 7, 2024

View reviewed changes

pablo-lua mentioned this pull request Mar 7, 2024

CiTestingConfig is blocking bevy_dev_tools from using bevy_render #12356

Closed

Update dependencies

38df5e1

alice-i-cecile mentioned this pull request Mar 7, 2024

Clarify purpose of bevy_dev_tools in crate-level docs #12358

Open

alice-i-cecile added the X-Controversial There is active debate or serious implications around merging this PR label Mar 7, 2024

matiqo15 reviewed Mar 7, 2024

View reviewed changes

matiqo15 mentioned this pull request Mar 7, 2024

Abstraction of bevy_dev_tools #12368

Open

pablo-lua added the S-Blocked This cannot move forward until something else changes label Apr 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move aabb gizmos to `bevy_dev_tools` #12354

Move aabb gizmos to `bevy_dev_tools` #12354

chompaa commented Mar 6, 2024 •

edited

github-actions bot commented Mar 6, 2024

alice-i-cecile Mar 6, 2024

pablo-lua left a comment

chompaa commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 •

edited

chompaa commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 •

edited

github-actions bot commented Mar 7, 2024

mgi388 commented Mar 7, 2024

alice-i-cecile commented Mar 7, 2024

mgi388 commented Mar 7, 2024

afonsolage commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 •

edited

matiqo15 Mar 7, 2024

pablo-lua Mar 7, 2024

pablo-lua Mar 7, 2024

matiqo15 Mar 7, 2024

pablo-lua Mar 7, 2024 •

edited

matiqo15 Mar 7, 2024

chompaa commented Mar 11, 2024

Move aabb gizmos to bevy_dev_tools #12354

Are you sure you want to change the base?

Move aabb gizmos to bevy_dev_tools #12354

Conversation

chompaa commented Mar 6, 2024 • edited

Objective

Solution

Migration Guide

github-actions bot commented Mar 6, 2024

alice-i-cecile Mar 6, 2024

Choose a reason for hiding this comment

pablo-lua left a comment

Choose a reason for hiding this comment

chompaa commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 • edited

chompaa commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 • edited

github-actions bot commented Mar 7, 2024

mgi388 commented Mar 7, 2024

alice-i-cecile commented Mar 7, 2024

mgi388 commented Mar 7, 2024

afonsolage commented Mar 7, 2024

pablo-lua commented Mar 7, 2024 • edited

matiqo15 Mar 7, 2024

Choose a reason for hiding this comment

pablo-lua Mar 7, 2024

Choose a reason for hiding this comment

pablo-lua Mar 7, 2024

Choose a reason for hiding this comment

matiqo15 Mar 7, 2024

Choose a reason for hiding this comment

pablo-lua Mar 7, 2024 • edited

Choose a reason for hiding this comment

matiqo15 Mar 7, 2024

Choose a reason for hiding this comment

chompaa commented Mar 11, 2024

Move aabb gizmos to `bevy_dev_tools` #12354

Move aabb gizmos to `bevy_dev_tools` #12354

chompaa commented Mar 6, 2024 •

edited

pablo-lua commented Mar 7, 2024 •

edited

pablo-lua commented Mar 7, 2024 •

edited

pablo-lua commented Mar 7, 2024 •

edited

pablo-lua Mar 7, 2024 •

edited