bevy_world_serialization depends on bevy_camera unconditionally in 0.19

[mitchty]

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.

[alice-i-cecile]

This is a perfectly normal use case, and something that should be fixed.

[Functionhx]

Happy to pick this up — make bevy_camera optional behind a feature flag in bevy_world_serialization.

[alice-i-cecile]

Happy to pick this up — make bevy_camera optional behind a feature flag in bevy_world_serialization.

Why does bevy_world_serialization need this at all?

[Functionhx]

Good point. I’ll first check whether bevy_camera is actually used by bevy_world_serialization. If it isn’t, removing the dependency entirely would be cleaner than feature-gating it.

[Functionhx]

Checked: bevy_world_serialization only uses bevy_camera for #[require(Visibility)] on WorldAssetRoot and DynamicWorldRoot. Would the intended fix be to remove those annotations and the dependency entirely? I’m happy to open a PR.

[alice-i-cecile]

Yeah, I think we can just remove those with a migration guide.