Remove `debug` Feature In Favor of Runtime Configuration
odecay opened this issue · comments
Description
Would it make sense to include a cargo clippy --features=debug somewhere in our CI?
I have noticed on multiple occasions that debug features end up broken since we currently have no checks for them, and when refactoring it is easy to forget to unregister a component from bevy-inspector-egui or some other small thing. If it takes too much time and needlessly slows down our workflow for commits I don't mind not having it, since debug features are not really user facing and I have currently been dealing with it by just doing the small fixes required.
There is also --features=schedule_graph but this is used even more rarely so I'd probably advocate for not checking against it.
Alternatives
Not doing this if it causes annoyance to PR workflow.
I wonder if maybe we could take another approach and remove the feature completely, allowing the debug features to be enabled at runtime with a engine config flag.
That would prevent the different codepaths and CI checking, and it would allow more powerful debugging features for users who decide to test out modding without having them need to download a debug enabled build or else compile it themselves.
I wonder if maybe we could take another approach and remove the feature completely, allowing the debug features to be enabled at runtime with a engine config flag.
I think that's a good idea. I always hate greyed out code
I wouldnt mind that, it would remove the annoyance of not having rust-analyzer pick up the debug features as well.
I dont know if that would work for the schedule graph? But that also is much less essential to have checked than debug features, and much less likely to break.
I dont know if that would work for the schedule graph?
I feel like we could leave that one as a feature flag and probably no reason to check in CI. It seems like one that's rare even for developers and would probably never be used by modders.
Yeap sounds good to me.