Support Removing Required Components at Runtime

[omaskery]

What problem does this solve or what need does it fill?

We are adding the ability to require components in Bevy, this feature request asks for the ability to override this behaviour when it prevents you from customizing third party code.

For example, suppose you're using some hypothetical Bevy provided components & systems:

Suppose there are components:

• SpecialComponent (which requires Transform),
• Transform (which requires GlobalTransform), and
• GlobalTransform.

Suppose there is the system: update_globaltransform_for_specialcomponents_with_transforms.

You're having a great time, until you reach an edge case where your requirements deviate from Bevy's assumptions, so you try to swap out some types:
You create a new component: BetterTransform.
You create a new system: update_globaltransform_for_specialcomponents_with_bettertransforms.

Pre-"Required Components": you would be unable to use bundles that assumed SpecialComponent should use Transform, potentially defining your own new bundles for convenience, but you'd be able to move on and achieve your goals.

In a world with "Required Components": you cannot currently "un-require" Transform from SpecialComponent in 3rd party code (without forking), resulting in this situation:

Your types end up with all of the components: SpecialComponent pulls in Transform, you add BetterTransform, Transform and BetterTransform pull in GlobalTransform.
You end up with two systems trying to compute the GlobalTransform for SpecialComponents:
update_globaltransform_for_specialcomponents_with_transforms, and
update_globaltransform_for_specialcomponents_with_bettertransforms.

What solution would you like?

Currently the required components are authored using an annotation. This feature request proposes that methods be added to Bevy's App type for customizing them dynamically, a hypothetical set of methods:

• app.add_requires::<DependantComponent, RequiredComponent>();
• app.remove_requires::<DependantComponent, RequiredComponent>();

(Names bike-sheddable as always!).

These would, as the names hopefully suggest, dynamically (un)register the "required components" relationship between those two types. The annotations in the current implementation would just be a short-hand for automatically registering these relationships.

What alternative(s) have you considered?

Extensive discussion in Discord (the Next Generation Scene/UI Working Group channel), including but not limited to:

• Not having required components (because BSN might add good enough Nested Scenes to address the need)
• A full-fledged "provides" system where instead of requiring a component you require some contract that other components provide
• ???

Effectively, Required Components are going in (soon? today? already?), so we're committed to experimenting with those and learning from it. This feature request effectively acts as a short-term solution to ensure the addition of Required Components doesn't cause a surge in use that prevents customizability.

Additional context

N/A

[alice-i-cecile]

Great writeup, and I think this is an essential escape hatch. I think that the relatively straightforward "just register / unregister required components" is the right call for now.

[NiseVoid]

Since @alice-i-cecile asked me to put my more detailed description of provides here:

Components can register theirselves as providing another component. If we want to add Transform, but the entity already has a component providing Transform, it does not need to be inserted. Alternatively this could be extended to a tuple of components providing another component, for example (Position, Rotation) could provide Transform.

Some interesting usecases for this would be replacing things like Transform that still have a well-defined edge to write back to (GlobalTransform in this case), or systems working with trait queries that might require some default but allow you to overwrite it.

This feature could of course be extended in many ways (like making things mutually exclusive if we ever get archetype invariants), but for this usecase having it as a way to avoid required components inserting unwanted components would be enough.

(This idea was originally brought up by @NthTensor, which in turn was inspired by another idea from Joy relating to plugin dependencies)

[alice-i-cecile]

Long-term, I think we're going to want both: provides is a good mechanism for plugin authors, but the simple override is more suitable for end users.

[cart]

Required Component Overrides

In general I think this is a pattern we should not be encouraging. If some third party SpecialComponent requires Transform, then that third party code (and other third parties that depend on it) can and should be written under the assumption that it will have a Transform.

A developer choosing to break that assumption risks breaking third party code in unexpected and arbitrary ways. And as these dependencies update, they risk adding new cases that also break.

Encouraging the "remove arbitrary upstream components" pattern is abstraction-breaking and "ecosystem stability"-hostile.

The ability to remove a required component constraint is an "unsafe escape hatch". If we were to include it, I think we'd want to heavily discourage its use in 3rd party plugins.

I also think we should heavily reconsider adding a global app.remove_requires::<SpecialComponent, Transform>(), as that is a blunt-force tool that could break things that rely on that behavior. I strongly suspect that anyone trying to do this wants to do it in specific contexts. Therefore, I think we should consider implementing this as an extension of the per-component require API:

#[derive(Component)]
#[require(SpecialComponent)]
#[remove_require(SpecialComponent, Transform)]
struct MySpecialComponent;

This would mean that existing uses of SpecialComponent do not break. This comes at the cost of needing to specify MySpecialComponent instead of (or in addition to) SpecialComponent during spawn. But it also means we aren't reaching in and invalidating existing upstream assumptions (which again, is pretty much never a good idea).

"Provides" API

In the context of a provides API, given that the computation has to happen somewhere, how is #[provides((Position, Rotation), Transform)] any different from this? Why do we need a new abstraction?

#[derive(Component)]
#[require(Transform)]
struct Position {
  x: f32,
  y: f32,
  z: f32,
}

#[derive(Component, Default)]
#[require(Transform)]
struct Rotation(Quat);

#[derive(Component)]
#[require(Transform)]
struct MyThing;

commands.spawn((
  MyThing,
  Position { x: 1.0, y: 0.0, z: 0.0 },
  Rotation::default(),
));

fn sync_position_rotation(query: Query<(&Position, &Rotation, &mut Transform)>) {
  // sync code here
}

[alice-i-cecile]

For more context, Transform is the only component that I've ever seen this sort of replacement requested for. Nothing else is similarly deeply integrated, and Transform itself has a number of limitations / frustrations that aren't ideal for all users. In particular:

• no f64 support
• no interpolation
• difficulty controlling what properties get inherited
• wasteful and unergonomic for 2D

It may be that the best solution here is to close this as Won't Fix (following Cart's points about abstraction breaking), but work harder to make sure that Transform can meet the needs of all of our users by solving some of these problems (or at least making more behavior configurable).

[NthTensor]

This is the general idea of Provides, which seems really different from your example.

#[derive(Component)]
struct A;

#[derive(Component)]
#[provides(A)]
struct B;

#[derive(Component)]
#[requires(A)]
struct C;

commands.spawn((B, C)); // does not insert A

The idea is that inserting (Position, Rotation) would opt-you-out of getting a Transform.

Without a mechanism like this it will quite difficult to alter the existing semantics of a component imported from a dependency. That dosn't seem very "Modular: Use only what you need. Replace what you don't like" to me.