Skip to content

Add a logging framework #89

@caspark

Description

@caspark

What

Add a logging framework of some kind.

Why

  • When working on this codebase, I often find myself adding (e)println debug statements, which I then need to remove before PRing - even though often this logging would be useful to me or the next contributor further down the line.
  • There are some cases where it would be helpful to just warn the user of something suboptimal instead of failing an assert (and crashing the app) or silently doing something.
  • There's currently a println!() in P2PSession that's fairly easy to trigger with bad connections or conservative max_prediction_window, which a) is ugly and b) won't print anything on a wasm build.

Options

Some approaches:

  • A) the log crate. Simple and easy to use for clients with many backends/adaptors available, including one that pushes log messages to tracing (although the default output is kinda ugly, with a lot fields being included).
  • B) the tracing crate. It's more complicated, but also used by bevy out of the box, and given that bevy seems to be by far the most popular Rust game engine, that should probably count for a fair bit (and I say that even though I don't use bevy myself).
  • C) write a shim to abstract over both log and tracing (maybe someone has already done this?), and users enable a feature flag to choose which one they want.

I'm open to any of these really, with a slight preference to B as tracing is what I use in my game and it's simpler to only add support for one.

I have also already added a bunch of useful logging statements in my personal ggrs fork, so I can port them over in a PR that actually adds logging.

So, which approach do we want to go with?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions