Add runtime system insertion

[Alainx277]

Objective

• Allow insertions of systems at runtime
• See [Feature] Runtime Dynamic Components and Systems ( To Support Scripting Initiatives ) #142

Solution

• Adds a new type of command that operates on the schedule
• The schedule applies the commands after it ran all stages

Further work

• Once we can operate on the schedule from systems, we may add more capabilities (removing systems, adding stages, ...)

[alice-i-cecile]

@Alainx277 could you comment in #2358 #2373 to confirm that you're okay dual-licensing this under Apache + MIT?

[alice-i-cecile]

bors try

[bors]

try

Build failed:

• build (stable, ubuntu-latest)

[mockersf]

@Alainx277 could you comment in #2358 to confirm that you're okay dual-licensing this under Apache + MIT?

it's #2373

[alice-i-cecile]

This is a cool bit of functionality, and the code quality is solid. Eventually we'll want a complete "dynamic_schedule.rs" example, but I'm not sure that's useful with just the one function.

Architecturally, I'm worried about reinventing the wheel and leaky abstractions prominent in the new run_exclusive function that takes in schedule_commands explicitly. I would prefer if we either:

1. Extended the Command trait to also take a &mut Schedule in its write method, and then just allow commands to mutate the schedule.
2. Used the same mechanisms as Commands to create a dedicated ScheduleCommands.

Either way, we'd need to update apply_buffers to also operate on the schedule. Exclusive systems should also probably have the ability to modify the schedule.

[alice-i-cecile]

bors try

[bors]

try

Build failed:

• build (nightly, ubuntu-latest)

[mockersf]

CI failure for unrelated nightly issue

[Alainx277]

1. Extended the Command trait to also take a &mut Schedule in its write method, and then just allow commands to mutate the schedule.

We cannot get a mutable reference to Schedule while running in a stage, as we already mutably borrow the Stage from Schedule.

2. Used the same mechanisms as Commands to create a dedicated ScheduleCommands.

I'm not sure what you mean by this? There already is a ScheduleCommands as a system parameter.

Either way, we'd need to update apply_buffers to also operate on the schedule. Exclusive systems should also probably have the ability to modify the schedule.

Same problem as with 1.

[mockersf]

Implementation looks good 👍

I dislike the name ScheduleCommand as it's ambiguous:

• is it to schedule a command?
• is it to issue a command to the schedule?

I think SchedulerCommand would lift the ambiguity, what do you think?

Also, for exclusive systems:

• this becomes the only parameter that can't be obtained from world. while it makes sense, it's a change from other parameters
• it adds a cost for every exclusive system, even if not issuing a ScheduleCommand

The PR could do with more doc comments and an example, that can be added in a followup

[Alainx277]

I think SchedulerCommand would lift the ambiguity, what do you think?

Agreed!

• it adds a cost for every exclusive system, even if not issuing a ScheduleCommand

I'm not sure how we could reduce the impact, any suggestions?

[TheRawMeatball]

bors try

[bors]

try

Build failed:

• build (stable, ubuntu-latest)

[TheRawMeatball]

bors try

[bors]

try

Build failed:

• build (stable, ubuntu-latest)

[TheRawMeatball]

bors try

[bors]

try

Build succeeded:

• check-doc
• build (stable, macos-latest)
• build-wasm (stable, ubuntu-latest)
• build-wasm (nightly, ubuntu-latest)
• build (nightly, ubuntu-latest)
• build (stable, ubuntu-latest)
• markdownlint
• check-missing-examples-in-docs
• check-markdown-links
• run-examples
• check-unused-dependencies
• build (stable, windows-latest)

[mockersf]

the example crashes for me after around 20 seconds, moving asset loading from the added system to the main system fixes that

[Ratysz]

Still not sure about some things.

1. Scheduler* or Schedule*? I really don't like having "scheduler" anywhere in the docs or API, it muddies the waters wrt how things are named and working under the hood. We have a schedule that describes the systems graph, and an executor that executes the systems graph. A "scheduler" sounds to me like something that creates or modifies the graph - which would be fitting here, but we don't have a dedicated command-accepting abstraction for that: the schedule modifies itself.

2. The queue is a field of World and not an optional resource. This mingles concerns of World and Schedule - not catastrophically, but it will be grating for standalone bevy_ecs users that don't use the schedule abstraction.

This is not a call to action, I'd like to discuss these points first.

[Nilirad]

I agree on point 1. The word "scheduler" gives the idea of an agent that creates or modifies a schedule. At this point of time the "scheduler" is actually the programmer, who specifies how systems are ordered and if/when they should run. It is true that the Schedule does some kind of scheduling job, but always in the limits of what the programmer dictated.

[Alainx277]

This PR is obsoleted by the new stageless scheduler.