Restrict available methods on App from Plugin::Build()

[Vrixyz]

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

When implementing a Plugin, a user has some footgun available:

• calling App::run(), would result in an early launch of the app, handled by plugin, resulting in a partly initialized app to run. On discord a user had this problem and it was not so trivial to track. See final fix there: Sheepyhead/prepare_two_die@3586bcd#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759L29

What solution would you like?

Ordered from my personal preferred to less preferred:

If there are no uses to run an App from a Plugin::Build, a user shouldn't be able to, we could either:

• pass ownership to App::run(self), the same way run_once works, so we couldn't call that from Plugin::Build because we have a &mut App.
• Leverage the type system to avoid having App::run() and other footguns being available within the Plugin::Build() function body.

If there exists reasons (I'm curious to hear about them) to indeed run an app from a plugin, we could either:

• Do the above, but provide another function like build_advanced allowing such rare behaviour ?
• Add a warning when starting the app from a non-conventional place, offering a way to suppress those ?
• Use tooling akin to ReportExecutionOrderAmbiguities to offer advanced diagnostics.

[alice-i-cecile]

Related to #1255, #2160 and bevyengine/rfcs#33.

My preference is to remove the build paradigm entirely, and instead provide a structured approach for plugins to hook into.

There are a fixed number of things plugins can do (add systems, initialize types, add resources, set the runner, ...) and we could have defaulted trait methods to allow end users to only specify the properties that they wish to set.

That approach eliminates this footgun, enables order-independence, and makes it clearer to users how plugins are meant to be used.

[alice-i-cecile]

That said, I think that simply passing ownership to App::run is a good simple solution for now, and should be implemented ASAP.

[bjorn3]

pass ownership to App::run(self), the same way run_once works, so we couldn't call that from Plugin::Build because we have a &mut App.

This would make it impossible to do either App::build().add_plugin(Foo).run() or let mut app = App::build(); app.add_plugin(Foo); app.run(); as either add_plugin accepts and returns the app by value in which case app.add_plugin(Foo); doesn't work, or it accepts and returns app by mutable reference in which case .run() doesn't work.

Maybe App could have a private field indicating if it is in the middle of an .add_plugin() operation and panic on .run() in that case?

[Vrixyz]

Indeed we would lose function chaining, see diff on 3d_scene example:

Your comment might be interpreted as that solution would NOT work, but I'm positive that the code I linked works with App::run() taking ownership of app.

That said, I fully agree that losing function chaining is very suboptimal so I'll try to implement your suggestion 👍 .