Use structured logging

[blakejameson]

Implemented the beginning stages of a Logger class

The logger is used in replace of the debug_print and print statements.

Regarding the error_print statements, I have currently refactored the error_print function to use the logger internally. The error_print has an increment to self.c_error_count, so refactoring wasn't a simple switch to the logger error message and required some thought to approach a refactor. I am following Nate's guidance to refactor this section after his and Taylor's merge to the change counters (#93 #95).

This logger class currently has the functionality to format key, value pairs into a json string, which can be printed to standard output.

Currently, there IS NOT the ability to save these logs to a file. This functionality is a longer-term objective.

I tested this code by running it on a v4b board, and the output shows similar to the main branch, the only difference of course seeing the output in json

[blakejameson]

NOTE:
Recently rebased onto main after the hardware init PR was merged in.

Resolved merge conflicts, but am currently running into an error and board ends up crashing. Need to explore and mitigate the issue

[blakejameson]

This was a lot of work and it's almost in! I like the logger interface that you created, that looks nice and easy to use. I noticed some repeated code in the logger implementation. What do you think of this? #109?

I know the old logger in this repo tracked file names and I played around with the concept of tracking filenames with the interface you created for this logger but I'm just not won over. Log messages are usually unique enough to help track down issues, tracking files adds boiler plate filename= vars at the top of every file that wants to use it, and I don't see this kind of tracking in other loggers so what about nixing it all together?

Thank you for the feedback in #109

Regarding the filenames, I am with you. It didn't feel quite right regarding the 'filename=' at the top of different files and felt kinda clumsy or awkward. I am definitely supportive of getting rid of the filename parameter

[nateinaction]

You made quick work of that review yesterday! Awesome! I've left a few comments and suggestions on calls to the logger that could be implemented in more places the themes for the call outs are:

• Remove the message= key from the first argument in each logger call
• Ensure that every call to the logger has a non-empty message
• Move all variables injected into message strings to use key/value pairs (kwargs) that you feed to the logger
• Add tests for all of the public functions you've created in logger.py

Because of the conflicts with this large change, I want to make sure this is the next thing that goes in if we can so thank you for the quick follow up.

What do you think of the proposed changes?

[nateinaction]

Noting for the future that we talked about removing traceback and we couldn't find a reason to keep it. We tried both in repl and found that reporting back the exception var e gave the same output but maybe we missed something. 🤷

[nateinaction]

Had a few final comments. What are your thoughts?

Not directed at you or this PR but oof @ that big try/except block in cdh.py. Cleaning that up could make logging nicer but that makes sense to do in another PR.

[nateinaction]

Great job!