Bevy should deny `eprintln` and `println` and prefer `log` and/or `tracing`

[BenjaminBrienen]

Exactly, I wonder if Bevy should actually prohibit eprintln and println since we always have access to log and/or tracing...

Originally posted by @bushrat011899 in #17442 (comment)

[mockersf]

there are some places, mostly parts of bevy_ecs, app initialization or in tests, where we can't assume a logger has been setup. well, and logger setup itself 😄

[bushrat011899]

there are some places, mostly parts of bevy_ecs, app initialization or in tests, where we can't assume a logger has been setup. well, and logger setup itself 😄

Since this should be the exception rather than the rule, perhaps we could deny e/println!, and then explicitly expect its usage in the (hopefully small) number of places it's required?

[mockersf]

Yup!
println is a big enough trap that it's probably worth it, but it's not as simple as forbid and replace all

[BenjaminBrienen]

Can you deny macros in deny.toml? If you can, I think you can expect the lint in the exceptional places.

[bushrat011899]

It looks like there's a provided lint, print_stdout that can be used for this, so we don't even need to deny the methods (which as @BenjaminBrienen points out might not be possible since these are macros). I'll need to test to see if it also applies to eprintln too.

[mockersf]

I'll need to test to see if it also applies to eprintln too.

Probably not as there's a print_stderr lint