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

[Draft] - logging #3657

Closed
wants to merge 3 commits into from
Closed

[Draft] - logging #3657

wants to merge 3 commits into from

Conversation

noklam
Copy link
Contributor

@noklam noklam commented Feb 27, 2024

Description

This draft PR is not ready for merge, but rather facilitate the discussion of the issues above.

Development notes

Changes:

  1. Read logging.yml automatically - be3d28d
  2. Change default of logging.yml- 65cf2a0 . This challenge the idea of "project logging". Why is logger necessary? It's more common to have module level logger, which propagate log to the "root logger", and set the level for root logger only. The exception here is "info logger" because it should only filter INFO level. If anything logger should be optional, not default. I also think it's more likely you want to keep the level consistent for any logger you have manually configured, it's rare you want kedro at INFO but project at DEBUG (This become less important if we end up introduce -v or -vv
  3. Add kedro run -v 2ec8bc1 . The main problem for this is CLI argument is slightly too late, there are chance that some log is produced before a "run" start. There is also question of extending this to all CLI command, because logging.yml affect any Kedro CLI. While this introduce a slight inconsistency, I don't think this is a big problem. As I envision this is mainly for debug use.

I imagine -v, -vv is a runtime config that used mostly for debugging. If users has sophisticated configuration, they can continue to use logging.yml to have different group of settings (I haven't seen much tbh)

Alternatlive, I found pip utilise something called a VerboseLogger

Developer Certificate of Origin

We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a Signed-off-by line in the commit message. See our wiki for guidance.

If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.

Checklist

  • Read the contributing guidelines
  • Signed off each commit with a Developer Certificate of Origin (DCO)
  • Opened this PR as a 'Draft Pull Request' if it is work-in-progress
  • Updated the documentation to reflect the code changes
  • Added a description of this change in the RELEASE.md file
  • Added tests to cover my changes
  • Checked if this change will affect Kedro-Viz, and if so, communicated that with the Viz team

@noklam
Copy link
Contributor Author

noklam commented Feb 28, 2024

Quick notes:
@antonymilne give some good insight:

  • Automatic loading logging is fine, but there are edge cases with CONF_SOURCE. I think it's still an improvement and it doesn't make anything worse in the current states.
  • We should never change root logger level by default, it's too disruptive. We can however, try to catch kedro-xxx pattern, but always respect the package logging level if it exists.
    • Alternative is we required user to add a new logger in logging.yml manually, would be annoying for plugins.
  • kedro run should still default to INFO, so nothing change in terms of default user behavior, -v to change to DEBUG level.

Maybe kedro run -v only affect the project logging, or kedro(and plugins). We should make sure the logs that get produced doesn't print logs from 3rd party package.

@antonymilne
Copy link
Contributor

antonymilne commented Feb 28, 2024

Some more information now I've found the old issues I wanted to refer to....

@noklam noklam closed this Apr 30, 2024
@merelcht merelcht deleted the noklam/change-logging branch October 31, 2024 15:55
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

Successfully merging this pull request may close these issues.

2 participants