Should bevy_transform be two crates?

[finegeometer]

I almost posted this as an issue, before I noticed the "Discussions" button. I'm still not sure which I should have done.

Question

In Bevy's README.md, it states that one of the design goals is to be modular; a user can choose to use only those features they need.
Yet the crate bevy_transform seems to bundle two unrelated concerns:

• The concept of a parent-child hierarchy of entities.
• The concept of a Transform, roughly a similarity transformation of Euclidean space.

bevy_transform's description in Cargo.toml even admits this — "Provides hierarchy and transform functionality for Bevy Engine"! (Emphasis mine.)

Why aren't these two separate crates, with the latter depending on the former?

Why I'm Asking

I discovered this issue while exploring the possibility of using Bevy to make games that take place in curved space.
The concept of a parent-child hierarchy is still completely applicable. But Transform, at least as implemented in Bevy, is not.

Details of Code Splitting

To ensure that this crate splitting would actually work, I tried it in a clone of the repository. Here are the results.

The crate bevy_transform was split into two: bevy_hierarchy and bevy_transform.

bevy_hierarchy contains these things:

• Everything in the modules components::{children, parent}.
• Everything in hierarchy and its submodules, except for the test in hierarchy::hierarchy_maintenance.

It has dependencies bevy_ecs, bevy_reflect, bevy_utils, and smallvec.
It does not need bevy_app or bevy_math.

bevy-transform contains everything else:

• Everything in the modules components::{transform, global_transform}.
• Everything in the module transform_propagate_system.
• Everything in the root module.
• The test from hierarchy::hierarchy_maintenance.

It depends on the new bevy-hierarchy, as well as bevy_app, bevy_ecs, bevy_math, and bevy_reflect.
It does not need bevy_utils or smallvec.

A few changes were necessary to get bevy_transform to compile again:

• Some imports needed to be fixed.
• In three instances, the code children.0.iter() started failing, because the field children.0 is private, and is now defined in a different crate. This was easily fixable; just do children.iter() (using the Deref impl) instead.

Finally, the dependent crates needed to be adjusted.

• bevy_scene depends on bevy_hierarchy, but not bevy_transform.
• bevy_gltf and bevy_ui depend on both bevy_hierarchy and bevy_transform.
• bevy_internal needed bevy_hierarchy added to its reexports and prelude.
• bevy_pbr, bevy_render, bevy_sprite, and bevy_text, despite depending on bevy_transform, seem to need no changes.

cargo --test passes. The few examples I tried seem to still work. I did not do any performance testing.

[TheRawMeatball]

As an FYI, we're in the process of making hierarchical structures and more generally, graph-like data structures a core ECS feature with #1627 (rfc: bevyengine/rfcs#18). This kind of split could still be useful however, as it would enable bevy_scene to work without bevy's transform.

[finegeometer]

I no longer think this suggestion is a good idea. See the comments on pull request #2789.