This is very much not ready for review. I will undraft this PR when it is.

@sahansk2 Does this actually solve #279? There are two specific things we wanted to log, can you add them? This is simple enough to get us started and hopefully to get into the habit of logging errors using the logger.

On another note, do you think we should convert all print statements to use the logger?

Also, can you merge master so you can get the GitHub Actions

This will solve #279, but it doesn't right now. I wanted to make a draft PR ahead of time so that we could double check on progress as it's developed.

The biggest issues that I have right now are basically:

• How do we set up a single logger to simultaneously log to two different files?
• How do we automatically log exceptions without wrapping everything in a try-except block? I'm hesitant of doing this simply because it might obscure some exceptions, like how a KeyError in a level's status method causes Git Gud to raise an unrelated exception ("Current level doesn't exist").

We shouldn't convert everything to logging (see here), but we could definitely convert some print messages to logging (e.g. Current level doesn't exist.)

@sahansk2 Does this help? https://stackoverflow.com/questions/11232230/logging-to-two-files-with-different-settings

I think for logging, we can take a simple first approach of simply logging things whenever we think it's necessary, so if there's an exception, include a line with logger.info(information)

@sahansk2 Does this help? https://stackoverflow.com/questions/11232230/logging-to-two-files-with-different-settings

Unfortunately, not really. It would be a bit of a hassle on our end to always output to two loggers, one error.txt and one YYYY-MM-DD-HH-mm.txt.

I just thought of this, though: what do you think about having a wrapper function, gitgud_logger(*args, **kwargs) that sends args and kwargs to two logger objects simultaneously? That would make logging much easier for us, and we can also use the two-file approach with error.txt and the time-specific file.

I see what you mean. What if when users had errors, we just logged it all to one file and had them send that file to us?

I think that could be good for a first iteration. Right now, we're not even sure how errors will be coming up

I see what you mean. What if when users had errors, we just logged it all to one file and had them send that file to us?

That could work, but it might be difficult from a development perspective to sift through it and see the most important errors. Having an error.txt with the most recent issue is the best approach for now. A bug tracking system would be nice to have; we'd probably want it to be opt-in (for automatic), or on a case-by-case basis, along with some method to strip identifying information.

This thread was speculative in terms of what we think will be useful. It's better to wait until we know how we can make something useful, so I'm closing this.