Bevy version and features
- bevy 0.19.0
- In this case I found this from switching a cli only app to bevy replicon, which by default does use default bevy features. But I would argue world serialization shouldn't unconditionally depend on gui crates or at least should optionally depend upon gui crates based on bevy feature flags.
Ref:
https://github.com/bevyengine/bevy/blob/release-0.19.0/crates/bevy_world_serialization/Cargo.toml#L30
[Optional] Relevant system information
n/a
What you did
Describe how you arrived at the problem. If you can, consider providing a code snippet or link.
In this case just added bevy replicon which added a default bevy feature flag to a crate using:
bevy = { version = "~0.19", default-features = false, features = [
"libm",
"async-io",
"multi_threaded",
"bevy_log",
"async_executor",
"bevy_state",
] }
...
bevy_replicon = "~0.41";
This isn't really about replicon however and the fix to be clear was there, but I do want to at least bring this up as a possible issue with world serialization in the new 0.19 scene setup. I might be a weirdo using bevy for non gui application logic but I would argue non gui bevy apps might want to serialize the world in the future as well and do that without bringing in heaps of gui related bevy dependencies.
https://docs.rs/crate/bevy/latest/features#bevy_world_serialization
My workaround as a note was to just setup these features to side step the default features in bevy_replicon that caused cargo to start evaluating in all the other gui dependencies:
bevy_replicon = { version = "~0.41", default-features = false, features = [
"client",
"server",
] }
What went wrong
- I would expect world scene serialization to take into account if a bevy application is built with ui features or not. And if not obviously only gui related serialization would be impacted. I'm not sure if that is applicable or not or if serialization directly implies ui related components.
- Around 10MiB or so of dependencies depending on platform pop up where you might not expect them to causing needless compilation and final binary bloat.
Additional information
Should be pretty straightforward and not sure its a critical issue by any stretch of the imagination but happy to help to try fixing things if we know which top level feature flags might impact gui related serialization.
Bevy version and features
Ref:
https://github.com/bevyengine/bevy/blob/release-0.19.0/crates/bevy_world_serialization/Cargo.toml#L30
[Optional] Relevant system information
n/a
What you did
Describe how you arrived at the problem. If you can, consider providing a code snippet or link.
In this case just added bevy replicon which added a default bevy feature flag to a crate using:
This isn't really about replicon however and the fix to be clear was there, but I do want to at least bring this up as a possible issue with world serialization in the new 0.19 scene setup. I might be a weirdo using bevy for non gui application logic but I would argue non gui bevy apps might want to serialize the world in the future as well and do that without bringing in heaps of gui related bevy dependencies.
https://docs.rs/crate/bevy/latest/features#bevy_world_serialization
My workaround as a note was to just setup these features to side step the default features in bevy_replicon that caused cargo to start evaluating in all the other gui dependencies:
What went wrong
Additional information
Should be pretty straightforward and not sure its a critical issue by any stretch of the imagination but happy to help to try fixing things if we know which top level feature flags might impact gui related serialization.