[Feature]: Redesign logger module

[tomvothecoder]

Is your feature request related to a problem?

Likewise, the motivation in consolidating the logger functions is that python logging is "global" - different modules adding stream or file handlers to their loggers accumulate across all logging.

Describe the solution you'd like

Now, there is a single "e2c_logger()" function in _logger.py, and it is called by ANY (code-accessible) module in e2c that requires logging. It can be configures to return the root logger, or a named-logger, to apply logging to a file or to console or both, and to propagate or not.

FIXING the problem where "--help" and "--version" cause a cmor_logs directory to be created in the user's current directory required some main-line refactoring. Previously, modules like mpas.py, handler.py, etc each would call their logger setup in the global space. That global space is activated whenever a module is "imported", irrespective of whether any functions defined within have been called. And ALL of these imports occur BEFORE we get a chance to parse the main command-line args (and discover that only --help or --version was being invoked.)

Now each of these modules has its own function to be called to set-up its logger. These are imported into "main" and invoked only AFTER arg-parsing is completed (and not at all for --help and --version calls).

Describe alternatives you've considered

No response

Additional context

Related to #229

[tomvothecoder]

Pulled from #261

[tomvothecoder]

Helpful information on how we can centralize logging to a root logger without duplicate messages being printed by logger handlers via propagate=True.

When should I propagate a logger message to the root logger?

GitHub Copilot: You should propagate a logger message to the root logger when you want to ensure that log messages are handled by both the specific logger's handlers and the root logger's handlers. This is useful in the following scenarios:

1. Centralized Logging Configuration: If you have a centralized logging configuration set up at the root logger level, propagating messages ensures that all log messages, regardless of their source, follow the same logging configuration and are handled consistently.

2. Multiple Handlers: If you want log messages to be processed by multiple handlers (e.g., writing to a file and printing to the console), propagating messages to the root logger can help achieve this without needing to add multiple handlers to each individual logger.

3. Global Log Management: When you want to manage log levels, formats, and handlers globally from a single point (the root logger), propagating messages allows you to control logging behavior across the entire application from the root logger.

4. Debugging and Monitoring: Propagating messages to the root logger can be useful for debugging and monitoring purposes, as it ensures that all log messages are captured and can be reviewed in a centralized location.

However, there are cases where you might not want to propagate messages to the root logger:

• Avoiding Duplicate Logs: If you have specific handlers for certain loggers and don't want duplicate log entries, you can disable propagation.
• Performance Considerations: Propagating messages to the root logger can add overhead, especially if the root logger has multiple handlers or performs expensive operations.

In summary, propagate logger messages to the root logger when you need centralized control and consistent handling of log messages across your application. Disable propagation when you want to avoid duplicate logs or have specific handling requirements for certain loggers.

Does propagating logger messages to the root cause duplicate logger messaging?

GitHub Copilot: Yes, propagating logger messages to the root logger can cause duplicate log messages if both the child logger and the root logger have handlers that output the messages. This is because the message is handled by both the child logger's handlers and the root logger's handlers.

Here's an example to illustrate:

import logging

# Set up the root logger with a console handler
root_logger = logging.getLogger()
root_handler = logging.StreamHandler()
root_logger.addHandler(root_handler)
root_logger.setLevel(logging.DEBUG)

# Set up a child logger with its own console handler
child_logger = logging.getLogger('child')
child_handler = logging.StreamHandler()
child_logger.addHandler(child_handler)
child_logger.setLevel(logging.DEBUG)

# Log a message with propagation enabled (default)
child_logger.propagate = True
child_logger.debug('This message will propagate to the root logger')

In this example:

• The message "This message will propagate to the root logger" will be output twice: once by the child logger's handler and once by the root logger's handler.

To avoid duplicate log messages, you can either:

1. Disable propagation for the child logger:

   child_logger.propagate = False

2. Remove the handler from the child logger and rely on the root logger's handler:

   child_logger.removeHandler(child_handler)

Choose the approach that best fits your logging requirements.