Skip to content

feat(Logs): allow configuration of logging levels #80

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

Merged
merged 3 commits into from
Mar 10, 2022

Conversation

richardkeit
Copy link
Contributor

  • Feature - Logging Levels

  • Current behaviour

Currently, this library unapologetically sets log levels across all loggers without configuration.
Results in all modules (outside of this library) logging in DEBUG, eg:

DEBUG:pynamodb.connection.base:Calling GetItem with arguments ....
  • Does this PR introduce a breaking change?

I would love to set some more sensible defaults, but have left the defaults as the original authors intended.
New functionaility will allow users customize to their preference

Anton0
Anton0 previously requested changes Feb 24, 2022
Copy link
Contributor

@Anton0 Anton0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - I think given this is a library intended for import we shouldn't be setting logging levels other than our own

But I'd probably prefer to remove the boto/nose etc log level setting as that's really beyond the scope of what we should be doing as you correctly point out.

I think INFO is a reasonable default as well, we don't have any DEBUG logging but just in case.

logging.getLogger("botocore").setLevel(logging.WARNING)
logging.getLogger("nose").setLevel(logging.WARNING)
logging.getLogger("urllib3").setLevel(logging.WARNING)
logging.getLogger().setLevel(os.getenv("LOG_LEVEL", logging.DEBUG))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
logging.getLogger().setLevel(os.getenv("LOG_LEVEL", logging.DEBUG))
logging.getLogger().setLevel(os.getenv("LOGLEVEL", logging.INFO))

Copy link

@matedge matedge Feb 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the existing convention in this file not lend itself more to LOG_LEVEL? (eg STAX_REGION, API_VERSION)

Copy link
Contributor

@Anton0 Anton0 Feb 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair as well - I'll happily accept either (the requested change to INFO aside)

The suggestion for LOGLEVEL was to fit what I could see libraries / projects using in the absence of a convention (I had a bit of a look around but nothing exhaustive) but it was not a strongly held position, I probably confused the issue by including it on the suggestion 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Anton0. We internally had some debate a few years ago about this same thing - LOG_LEVEL vs LOGLEVEL.

RE: the changing of boto3/botocore, I think it's reasonable to keep the WARNING. It was the "ALL" loggers to default which I thought was a bit too verbose.

@Anton0 Anton0 added the bug Something isn't working label Feb 25, 2022
@richardkeit richardkeit requested a review from Anton0 February 28, 2022 04:21
@samdammers
Copy link
Contributor

@richardkeit are you able to rebase now that #81 has been merged and we can get this one in as well.

@samdammers
Copy link
Contributor

@richardkeit just suggested swapping the values so default is INFO and the example is moving it to DEBUG. So everyone has a better default (than we do currently).

@richardkeit
Copy link
Contributor Author

@richardkeit just suggested swapping the values so default is INFO and the example is moving it to DEBUG. So everyone has a better default (than we do currently).

Hey @samdammers - typically I try keep changes backwards compatible, but if you're happy with change it, so am I :shipit:

@samdammers
Copy link
Contributor

👌 :shipit: :)

@richardkeit richardkeit requested a review from samdammers March 10, 2022 23:27
@codecov
Copy link

codecov bot commented Mar 10, 2022

Codecov Report

Merging #80 (c77422d) into master (708905e) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #80   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          434       434           
=========================================
  Hits           434       434           
Impacted Files Coverage Δ
staxapp/config.py 100.00% <100.00%> (ø)

Copy link
Contributor

@samdammers samdammers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this contribution!

@samdammers samdammers dismissed Anton0’s stale review March 10, 2022 23:29

Approved on behalf of

@samdammers samdammers merged commit b4c7f44 into stax-labs:master Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants