Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve logging practices/make hatchet logging opt in #114

Open
colonelpanic8 opened this issue Jul 27, 2024 · 1 comment
Open

Improve logging practices/make hatchet logging opt in #114

colonelpanic8 opened this issue Jul 27, 2024 · 1 comment

Comments

@colonelpanic8
Copy link
Contributor

Current Behavior

The library currently sets up logging configuration at the module level:

import logging
import sys
# Create a named logger 
logger = logging.getLogger("hatchet")
logger.setLevel(logging.ERROR)
handler = logging.StreamHandler(sys.stdout)
formatter = logging.Formatter("[%(levelname)s] hatchet -- %(asctime)s - %(message)s")
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.propagate = False

(here)

Additionally, this single hatchet logger is used throughout the library instead of module-local loggers.

Issues

  1. Inflexible Logging Configuration: The current setup makes it difficult for users to opt out of or modify the logging behavior. This limits the flexibility for applications that may need different logging setups (e.g., logging to files, using structured logging, or integrating with specific logging services).

  2. Single Logger Usage: Using a single hatchet logger throughout the library, instead of module-local loggers, makes it harder for users to have fine-grained control over logging from different parts of the library.

Proposed Changes

  1. Optional Logging Configuration: Make the current logging setup optional, allowing users to easily opt out or configure their own logging setup. I would even be fine if it were enabled by default without an explicit opt out somehow.

  2. Module-Local Loggers: Use module-local loggers (e.g., logging.getLogger(__name__)) throughout the library instead of a single hatchet logger.

Benefits

These changes would:

  • Provide more flexibility for users to integrate the library into their existing logging setups.
  • Allow for more fine-grained control over logging from different parts of the library.
  • Align with Python logging best practices for libraries.

Example of Good Logging Practices

For reference, SQLAlchemy provides a good example of logging practices in a Python library:
https://docs.sqlalchemy.org/en/14/core/engines.html#configuring-logging

Possible Implementation

  1. Move the current logging setup into a function that users can optionally call.
  2. Replace all instances of logging.getLogger("hatchet") with logging.getLogger(__name__).
  3. Update documentation to explain how users can configure logging.
@grutt
Copy link
Contributor

grutt commented Jul 29, 2024

@colonelpanic8 appreciate your detailed write up. we've been giving python some much needed love and will be sure to address this soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants