You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I struggled with the same issue when Bevy changed its renderer, to ensure both 2D and 3D could be used for bevy_hanabi. Initially the code had some 2d and 3d features, but they were mutually exclusive, which is equivalent to what you have now in bevy_debug_lines with a feature and its opposite.
For bevy_hanabi this caused a number of issues:
By default users have to choose, even before they know anything about the crate. This is not nice.
If you set a default, like you did here with 3d, then this hinders discoverability; users might miss that feature flag and end up not being able to use the crate in 2D and get confused, and either log an issue or eventually abandon and consider the crate is broken.
Obviously, with that setup you cannot use both 2D and 3D. This was already a problem for bevy_hanabi with particles, but for bevy_debug_lines that seems like an even harsher limitation, as games/apps commonly have a mix of 2D and 3D, and you don't want to find yourself having to choose which one you can line-debug and which one you cannot.
Having a mandatory feature doesn't play nice with some tooling like cargo test or code coverage. Being able to use --all-features on the other hand, and covering all codepaths that way, is quite handy.
Related, but more minor, is the fact the official Rust guideline for features is to be strictly additive. So in theory having some codepath activated by the absence of the 3d feature is breaking that rule. I know many crates break it anyway, and in particular no_std breaks that idiom, but cargo and other tools are working under that assumption of features being strictly additive, and sometimes things break if that's not the case.
Eventually the solution was to support both 2d and 3d features additively, each plugging into the appropriate renderer (see here for details). I think that's a nicer approach, and it's not that much more complicated to implement.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi-
I struggled with the same issue when Bevy changed its renderer, to ensure both 2D and 3D could be used for
bevy_hanabi
. Initially the code had some2d
and3d
features, but they were mutually exclusive, which is equivalent to what you have now inbevy_debug_lines
with a feature and its opposite.For
bevy_hanabi
this caused a number of issues:3d
, then this hinders discoverability; users might miss that feature flag and end up not being able to use the crate in 2D and get confused, and either log an issue or eventually abandon and consider the crate is broken.bevy_hanabi
with particles, but forbevy_debug_lines
that seems like an even harsher limitation, as games/apps commonly have a mix of 2D and 3D, and you don't want to find yourself having to choose which one you can line-debug and which one you cannot.cargo test
or code coverage. Being able to use--all-features
on the other hand, and covering all codepaths that way, is quite handy.3d
feature is breaking that rule. I know many crates break it anyway, and in particularno_std
breaks that idiom, butcargo
and other tools are working under that assumption of features being strictly additive, and sometimes things break if that's not the case.Eventually the solution was to support both
2d
and3d
features additively, each plugging into the appropriate renderer (see here for details). I think that's a nicer approach, and it's not that much more complicated to implement.Thanks!
The text was updated successfully, but these errors were encountered: