Merge bevy_app into bevy_ecs

[alice-i-cecile]

bevy_app is a thin layer over bevy_ecs, and is nearly impossible to use on its own. Moreover, most standalone uses of bevy_ecs would be better suited by using the tools provided with bevy_app; particularly if we had better documentation around custom runners and manually controlling the App loop.

For example: bevy_app re-exports all of bevy_ecs::event.

This is pointless, because bevy_ecs is an explicit dependency of all users of bevy_app. Furthermore, it creates confusion in the main Bevy docs, since the bevy_app version is listed.

This re-export can and should just be removed.

[DJMcNab]

The alternative is to make bevy_app export bevy_ecs somehow; bevy_app is meaningless without bevy_ecs anyways.

In some ways, I still think merging them probably makes sense; I can't recall a single usage of bevy_ecs without bevy_app which hasn't been misguided.

[CGMossa]

There are people that want to simply use bevy_ecs on its own. There are efforts put forth to de-couple bevy crates, e.g. #2931 comes to mind also.

[alice-i-cecile]

In some ways, I still think merging them probably makes sense; I can't recall a single usage of bevy_ecs without bevy_app which hasn't been misguided.

Yeah, this is about my perspective too. bevy_app is a very thin layer, and even if we roll it into bevy_ecs it can still be ignored.

[CAD97]

@CGMossa as the author of #2931: there's a difference here.

bevy_app is fundamentally a fairly thin usability layer on top of bevy_ecs, and doesn't add dependencies fundamentally different from bevy_ecs.

bevy_core, however, doesn't have a real "identity" in what it's for. It conflates multiple purposes, with the bevy_time functionality and glue code sort of arbitrarily in one location.

Moving the bevy_core components around as described in #2931 is an improvement to the organization of bevy code because it clarifies the internal dependency graph, and as a side effect, it makes it more practical to depend on a subset of said graph.

bevy_app and bevy_ecs could go either way; either bevy_app doesn't reëxport significant chunks of bevy_ecs, or bevy_ecs absorbs the orchestration of bevy_app. Either way could clean up the clarity of which crate does what, and merging the orchestration into bevy_ecs is simpler.

[mcobzarenco]

Only because bevy_app is a thin layer around bevy_ecs shouldn't by itself mean there is no value in keeping things specific to the game engine separate (e. g. CoreStage ).

Thinking of use cases where bevy ecs is used as a general purpose way of structuring an application as ECS outside game development; with a custom event loop, "stages" etc.

[alice-i-cecile]

Only because bevy_app is a thin layer around bevy_ecs shouldn't by itself mean there is no value in keeping things specific to the game engine separate (e. g. CoreStage ).

I agree, this and things like DefaultPlugins should live in either the root bevy module or something like bevy_core.

Then, move App, Plugin and schedule running logic into bevy_ecs.

[bjorn3]

What about instead moving Schedule out of bevy_ecs into bevy_app? This would make bevy_ecs store data, while bevy_app would store app logic.

[alice-i-cecile]

What about instead moving Schedule out of bevy_ecs into bevy_app? This would make bevy_ecs store data, while bevy_app would store app logic.

That's an interesting split. I like it better than our current setup. I wonder if that dividing line would continue to be clean as we add more functionality 🤔