Deprecate dynamic plugins

[BD103]

Objective

• The current implementation for dynamic plugins is unsound. Please see Deprecate current bevy_dynamic_plugin implementation #11969 for background and justification.
• Closes Deprecate current bevy_dynamic_plugin implementation #11969 and closes User-mode data execution prevention (DEP) violation when loading Dynamic Plugins #13073 and closes Unloading/reloading dynamic plugins #4843.

Solution

• Deprecate all dynamic plugin items for Bevy 0.14, with plans to remove them for Bevy 0.15.

Discussion

One thing I want to make clear is that I'm not opposed to dynamic plugins in general. I think they can be handy, especially for DLC and modding, but I think the current system is the wrong approach. It's too much of a footgun for the meager benefit is provides.

---

Changelog

• Deprecated the current dynamic plugin system.
  • Dynamic plugins will be removed in Bevy 0.15. For now you can continue using them by marking your code with #[allow(deprecated)].

Migration Guide

If possible, remove all usage of dynamic plugins.

// Old
#[derive(DynamicPlugin)]
pub struct MyPlugin;

App::new()
    .load_plugin("path/to/plugin")
    .run();

// New
pub struct MyPlugin;

App::new()
    .add_plugins(MyPlugin)
    .run();

If you are unable to do that, you may temporarily silence the deprecation warnings.

#[allow(deprecated)]

Please note that the current dynamic plugin system will be removed by the next major Bevy release, so you will have to migrate eventually. You may be interested in these safer alternatives:

• Bevy Assets - Scripting: Scripting and modding libraries for Bevy
• Bevy Assets - Development tools: Hot reloading and other development functionality
• stabby: Stable Rust ABI

[BD103]

I've added the "needs release notes" label, though I can be convinced otherwise. I don't know how large of an impact this change will make.

[alice-i-cecile]

Previously attempted in #3893

See #3893 (comment) for Cart's opinion at the time.

My position remains about the same as it was then:

1. Improving this crate is a poor use of our organizational time currently
2. There have been approximately 0 meaningful PRs to the crate ever
3. It presents a misleading and unsafe rabbit hole for new users

Given the presence of testing showing indications of UB during reasonable use, I think now's as good a time as any to officially drop support.

[mockersf]

maybe the deprecated comment could redirect to something like "go comment on this pr if you see this message" to encourage potential users to report back

[NthTensor]

I'd also like to express my support for this change. Aside from the correctness issues, the current version also effectively blocks some advanced plugin build ordering/order-independence features.

[BD103]

maybe the deprecated comment could redirect to something like "go comment on this pr if you see this message" to encourage potential users to report back

I added a deprecation notice in 1b97d99. Hopefully if the alternatives listed do not support someone's use-case, they will comment here. (It may help designing a new API!)

[soqb]

yeah, this makes sense. working with this crate requires a lot of finesse, and from my woes a few years 👀 ago, once you have the conceptual understanding needed to use this crate, its really not very much work to implement it from scratch yourself.

[nerdachse]

I am sorry, how again is this controversial? I haven't seen any comment indicating such.

[NthTensor]

This was controversial the last time it was tried, which makes this sort of controversial-by-default.

[BD103]

I am sorry, how again is this controversial? I haven't seen any comment indicating such.

@cart disagreed with this change last time it was attempted. (#3893 (comment)) No one has picked up dynamic plugins and tried to improve it since deprecating it was last attempted.

Furthermore, I think bevy_dynamic_plugin even existing in the main Bevy project is encouraging users to use it instead of making their own, better alternatives. As someone mentioned on Discord, Bevy has a reputation for reliability (partially due to being written in Rust). I would argue that dynamic plugins are quite unreliable, hurting this reputation. They are simple enough that if someone wanted to use them, they could just copy the code. I think they should do this, because it puts the responsibility on them and not us.

[cart]

I relent. A bit bummed that we're removing useful baseline functionality, but I agree that using it soundly is hard and that exposes people to risk. I won't fight this anymore :)

[alice-i-cecile]

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1321 if you'd like to help out.

[ethereumdegen]

It is disappointing to see that dynamic plugins are deprecated and unavailable because in my opinion, this is the absolute most important feature we need for a proper bevy editor. Without this, bevy editor plugins need to be hardcoded in the TOML file (correct?) which seems like a bad solution.

[bjorn3]

It is disappointing to see that dynamic plugins are deprecated and unavailable

You can still do dynamic plugins. If necessary by literally copying the code that was removed here into your own code.

this is the absolute most important feature we need for a proper bevy editor. Without this, bevy editor plugins need to be hardcoded in the TOML file (correct?) which seems like a bad solution.

The code that was removed here doesn't help much for a bevy editor I would think. It fundamentally requires you to link against the exact same libbevy_dynamic.so (and all .rmeta files for all (in)direct dependencies of bevy) compiled by the exact same rustc version, which you can basically only guarantee if you compile the editor yourself, at which point editing Cargo.toml for the editor wouldn't be much worse. Having actually usable editor plugins would require reflection and either something like stabby or wasm, neither of which would be able to benefit from the code that was removed in this PR anyway.

Disclaimer: This is my personal opinion and not representing that of any of the Bevy developers.

[BD103]

Agreed with @bjorn3. If we truly want dynamic plugins for the editor, there are better ways to accomplish that than this removed code.

(For example, what if editor plugins were distributed as WASM files? We could load and run them in a safe, sandboxed runtime with greater protections than dynamic linking.)