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

[Logger] - introduce a uniform system for logging information, warnings and errors across Supervision #835

Open
SkalskiP opened this issue Feb 1, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request Q1.2024 Tasks planned for execution in Q1 2024.

Comments

@SkalskiP
Copy link
Collaborator

SkalskiP commented Feb 1, 2024

Description

This system will empower users to selectively filter messages based on their importance or pause logging as needed.

Essential features of this upgraded system include:

  • Enable users to specify the severity level for each logged message, categorizing them as informational, warnings, or errors.
  • Ensure each log entry denotes its originating file, enhancing traceability and issue resolution.
  • Each entry in the log should carry a timestamp, marking the exact moment of occurrence.
  • Introduce a mechanism to regulate the frequency of log entries, preventing user inundation and enhancing readability.

Additional

  • Note: Please share a Google Colab with minimal code to test the new feature. We know it's additional work, but it will speed up the review process. The reviewer must test each change. Setting up a local environment to do this is time-consuming. Please ensure that Google Colab can be accessed without any issues (make it public). Thank you! 🙏🏻
@SkalskiP SkalskiP added enhancement New feature or request Q1.2024 Tasks planned for execution in Q1 2024. labels Feb 1, 2024
@iamhatesz
Copy link
Contributor

Hey @SkalskiP

I'd like to work on this issue, however I don't see there's a need for development work here.

Enable users to specify the severity level for each logged message, categorizing them as informational, warnings, or errors.
Ensure each log entry denotes its originating file, enhancing traceability and issue resolution.
Each entry in the log should carry a timestamp, marking the exact moment of occurrence.

This could be easily solved with the built-in logging:

LOG = logging.getLogger(__name__)

# ...

LOG.info("Doing something very important")

This captures the level of the message, location, and timestamp. Usually, it's up to the user to configure the logger to his preferences (formatting, handlers, etc.). If you think this might be useful, we can provide a helper setup_logger function that configures defaults for the supervision package. Even if users won't be interested in this feature, it still might be useful for developers.

Introduce a mechanism to regulate the frequency of log entries, preventing user inundation and enhancing readability.

Could you elaborate more on this requirement? So far, I've seen this useful for warnings (e.g. DeprecationWarning or UserWarning), but this is also available in the standard library (warnings). If you find this useful also for logging messages, I might introduce a filter for that.

@SkalskiP
Copy link
Collaborator Author

Hi @iamhatesz 👋🏻

  • The logger would primarily be useful for individuals contributing to Supervision rather than for users.
  • I would like a setup_logger to ensure a consistent logging format throughout the library.
  • Truthfully, using the logging would be convenient for me. I'd prefer not to add new dependencies to supervision.
  • Do you have any idea how to solve log suppression? Suppose you are processing a video, and the log would show for each frame, and we would like it not to happen more than once a minute.

@Bhavay-2001
Copy link

Hi @SkalskiP, is this issue for beginners? Can I give it a try?

@iamhatesz
Copy link
Contributor

Hey @SkalskiP! I've just submitted a PR for this: #925 Would be great if you can take a look

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Q1.2024 Tasks planned for execution in Q1 2024.
Projects
Development

No branches or pull requests

3 participants