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

Print level feature #33

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

SuperKogito
Copy link
Member

  • This PR solves option to only print red URLs? #29
  • This PR adds a --print-level feature and removes the old --print-all flag.
  • The --print-level has 4 printing levels:
    • all: all prints
    • files-with-urls-only: print only for files with urls in them.
    • fails-only: print only broken links.
    • success-only: print only working links.
    • none: no files or urls prints.
  • The tests and README are adjusted accordingly.

@SuperKogito SuperKogito requested a review from vsoch April 13, 2020 14:44
@codecov
Copy link

codecov bot commented Apr 13, 2020

Codecov Report

Merging #33 into master will increase coverage by 0.67%.
The diff coverage is 89.28%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #33      +/-   ##
==========================================
+ Coverage   77.03%   77.70%   +0.67%     
==========================================
  Files          20       20              
  Lines         627      628       +1     
==========================================
+ Hits          483      488       +5     
+ Misses        144      140       -4     
Impacted Files Coverage Δ
urlchecker/client/check.py 31.14% <0.00%> (+6.55%) ⬆️
urlchecker/core/urlproc.py 92.92% <88.23%> (+0.45%) ⬆️
tests/test_client_check.py 97.56% <100.00%> (-0.12%) ⬇️
tests/test_core_check.py 100.00% <100.00%> (ø)
tests/test_core_urlproc.py 100.00% <100.00%> (ø)
urlchecker/client/__init__.py 75.92% <100.00%> (ø)
urlchecker/core/check.py 83.01% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2279da0...f14fc12. Read the comment docs.

@vsoch
Copy link
Collaborator

vsoch commented Apr 13, 2020

Awesome! I’ll make some time to review this week.

@@ -45,7 +45,7 @@ def __init__(
# Save run parameters
self.white_listed_files = white_listed_files or []
self.include_patterns = include_patterns or []
self.print_all = print_all
self.print_level = print_level
Copy link
Collaborator

Choose a reason for hiding this comment

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

For all the places that print_level is set from a client, we have to assume that a user might set it to None, thinking this is default or "unset." So instead of just blindly setting it like this, let's do something like:

self.print_level = print_level or "none"

That way if it's set to an empty string or None, it will not break the client.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But since we favor verbosity, the default should be:

self.print_level = print_level or "all"

Copy link
Member Author

Choose a reason for hiding this comment

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

makes sense. I will make the change.

@@ -16,7 +16,7 @@
from urlchecker.logger import print_success, print_failure


def check_response_status_code(url, response):
def check_response_status_code(url, response, print_level):
Copy link
Collaborator

Choose a reason for hiding this comment

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

The default should be set here, to "all" I think?

@@ -61,7 +59,11 @@ def test_get_user_agent():
assert isinstance(user_agent, str)


def test_check_response_status_code():
@pytest.mark.parametrize(
"print_level", ["all", "files-with-urls-only",
Copy link
Collaborator

Choose a reason for hiding this comment

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

How is files-with-urls-only honored? I don't see it in the printing function, only the other four.

Copy link
Member Author

Choose a reason for hiding this comment

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

so files-with-urls-only is not explicitly specified in the code, because I did not need to. Covering the other cases was sufficient. So -as you already noticed- you barely see the variable in the code, but if used, it works as expected.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This doesn’t make any sense. Please provide an explicit example. If an option isn’t used I don’t understand why it exists.

@@ -30,16 +30,19 @@ def check_response_status_code(url, response):
"""
# Case 1: response is None indicating triggered error
if not response:
print_failure(url)
if print_level not in ["success-only", "none"] :
Copy link
Collaborator

Choose a reason for hiding this comment

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

What about files-with-urls-only?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't need it here, because I want to show failures when files-with-urls-only is specified.

):
self.file_name = file_name
self.print_all = print_all
self.print_level = print_level
Copy link
Collaborator

Choose a reason for hiding this comment

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

Especially if print_level is default to None here, setting the variable again needs to be:

self.print_level = print_level or "all"

@@ -167,13 +170,13 @@ def check_urls(self, urls=None, retry_count=1, timeout=5):

# if no urls are found, mention it if required
if not urls:
if self.print_all:
if self.print_level == "all":
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this should be subject to print level - this message should be printed to tell the user there are no urls regardless. I would remove this if statement here and restore to how it was.

Copy link
Member Author

Choose a reason for hiding this comment

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

Unfortunately I disagree, I totally get your point but I think merging all printing into one option with multiple choices is much better than having a flag and printing variable which can be confusing in my opinion :/

Copy link
Collaborator

Choose a reason for hiding this comment

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

The user needs to know if there are not any urls, which is different from just not printing results. If you want to control verbosity of non url messages then we can discuss adding a logger (also with levels) but shoving all printing under one variable because it’s easy is not appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

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

You got a point but It is not about easy or hard, the changes are not major. I just have the feeling that we are having a lot of input variables at this point, which is nice but it can be confusing to users.

@vsoch
Copy link
Collaborator

vsoch commented Apr 14, 2020

I think I’ve changed my mind about this feature - given the core use of url checker for CI runs, it feels like feature bloat, and I’m not convinced that this is the cleanest implementation to insert a bunch of random if/else all over the library. Implementing this with a logger type interface that calls a statement based on a level would be much more elegant. I think the work is still valuable and we should keep the PR for future feedback but I am not wanting to add this now to the library. Thanks for your work on this @SuperKogito though!

@SuperKogito
Copy link
Member Author

okay xD what made this sudden change of heart?

@vsoch vsoch added the wontfix This will not be worked on label Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants