Logging

[avmarchenko]

Is your feature request related to a problem? Please describe. Currently there isn't a systematic logging system for exatomic. The value could be both for debugging as well as more descriptive information about "handled" errors e.g. when a parser tries to parse a presumably correct file but fails to do so because the format of the file has changed slightly. Other use cases could be for logging widget information.

Describe the solution you'd like exatomic could in principle write a persistent log to ~/.exatomic/ or similar. Standard library logging configuration should do in this case (handles format, rotation, etc).

Describe alternatives you've considered Currently we don't have a logging solution implemented.

Additional context Looking for additional thoughts about this (originally suggested by @tjduigna !)

[tjduigna]

I def +1 this. I think it is important to set up a default RotatingFileHandler and persist logging (+1 for ~/.exatomic/). I find that it is also convenient (especially in a notebook context) to clone logging to stdout or stderr with a StreamHandler. Then we can configure different logging levels for different modes of run-time, managed through a logging.yaml configuration or some such.

What do you think of a base mixin offering a self.log property that gives its full "path" in its call to logging.getLogger?

Something like:

class LogMixin:
    @property
    def log(self):
        path = '.'.join([self.__module__, self.__class__.__name__])
        return logging.getLogger(path)

This could actually go all the way back to the exa library, adding this mixin to the Container, Editor, and DataFrame to offer a lot of control over developer logging API. If a specific nugget of logging information pertains to a dataframe within an editor, you can log from that dataframe's log, or if it is relevant to the parsing logic, perhaps the editor's log is more appropriate.