Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using additive 2d and 3d features #19

Open
djeedai opened this issue May 18, 2022 · 1 comment
Open

Consider using additive 2d and 3d features #19

djeedai opened this issue May 18, 2022 · 1 comment

Comments

@djeedai
Copy link

djeedai commented May 18, 2022

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 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!

@Toqozz
Copy link
Owner

Toqozz commented Jun 1, 2022

Thanks for the suggestion!

Yeah, I really hate the way we do 2d/3d separation at the moment, and I'm looking at anything I can do to make it... not crap.

Will definitely look into doing this when I have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants