configure root logger

[kzidane]

When instantiating cs50.SQL, logging.basicConfig is called. It adds a handler on the root logger, if one doesn't exist, which causes flask to not add its own default handler, in which case our _formatException isn't used. To replicate:

from cs50 import SQL
from flask import Flask

app = Flask(__name__)
# db = SQL('sqlite:///foo.db')

@app.route('/')
def index():
  raise Exception() # highlighted in yellow

from cs50 import SQL
from flask import Flask

app = Flask(__name__)
db = SQL('sqlite:///foo.db')

@app.route('/')
def index():
  raise Exception() # not highlighted in yellow

There's a couple of ways to fix this. One way is to add a handler to the root logger before flask's app.logger is accessed per https://flask.palletsprojects.com/en/1.1.x/logging/#basic-configuration so that flask doesn't add its own handler. This PR does that by calling logging.basicConfig to add a default handler to the root logger and patches formatException on this handler's formatter. As a result, flask's formatter isn't used, so we don't need to patch its formatException.

[kzidane]

Side note, some exception tracebacks are logged by werkzeug's logger as errors (not exceptions), so formatException isn't called for these, resulting in them not being highlighted in yellow. I don't think there's much we can do about this without PR'ing werkzeug.

https://github.com/pallets/werkzeug/blob/master/src/werkzeug/serving.py#L319

[dmalan]

Hm, so it occurs to me if we override the root logger, can users still enable/disable just our SQL logging, so they do/don't see parsed SQL queries on the command line? Should we perhaps be overriding the root logger for color-coding but still use our own cs50 logger for SQL query logging?

[kzidane]

Added separate logger per db0d14a.