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

Add whitelist for the pint package #258

Merged
merged 5 commits into from
Jun 11, 2022
Merged

Add whitelist for the pint package #258

merged 5 commits into from
Jun 11, 2022

Conversation

bje-
Copy link
Contributor

@bje- bje- commented May 3, 2021

Self-evident.

Copy link
Contributor

@RJ722 RJ722 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 the pull request @bje-!

I think that we need to think some more about shipping whitelists for non-stdlib modules with Vulture. I can think of the following options:

  1. We wrap the entire script in a try/except block which will only run if the module can be imported successfully.
  2. Use the proxy Whitelist module from whitelists/whitelist_utils.py.

@jendrikseipp any thoughts?


I also had an initial worry that using common names (like in this case, default_format) might be used too often altogether and that Vulture might miss them as false negatives, but now that I think of it, since we only import the whitelists only if the corresponding module is imported in user's program, I don't think this will be a problem.

@RJ722
Copy link
Contributor

RJ722 commented May 15, 2021

Oh I just found out #208 (comment) from @jendrikseipp:

Actually, i think it's good to use "real" source code in whitelists. That way, we can test that the names really exist and are spelled correctly. The whitelist files that are bundled with Vulture are only used when the corresponding module is imported, and even then the content is only parsed for names, not actually run, so no new dependency is needed. We only need to add flask or its extensions to the tox.ini testenv section and this allows us to actually run the whitelist file during testing.

I too think this is a good idea, and I think, it answers all the questions above.

@bje- can you add pint to the tox.ini testenv section? That should fix the CI and we should be good to go.

@bje-
Copy link
Contributor Author

bje- commented May 20, 2021

Like so?

Copy link
Owner

@jendrikseipp jendrikseipp left a comment

Choose a reason for hiding this comment

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

Looks good to me! Can you add a changelog entry, please?

@bje- bje- requested a review from jendrikseipp June 9, 2022 00:18
@codecov-commenter
Copy link

Codecov Report

Merging #258 (2aa0a4c) into master (ebd643d) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #258   +/-   ##
=======================================
  Coverage   99.37%   99.37%           
=======================================
  Files          18       19    +1     
  Lines         635      638    +3     
=======================================
+ Hits          631      634    +3     
  Misses          4        4           
Impacted Files Coverage Δ
vulture/whitelists/pint_whitelist.py 100.00% <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 ebd643d...2aa0a4c. Read the comment docs.

@jendrikseipp jendrikseipp merged commit 34e93b0 into jendrikseipp:master Jun 11, 2022
@jendrikseipp
Copy link
Owner

Thanks!

@bje-
Copy link
Contributor Author

bje- commented Jun 11, 2022

And thank you!

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.

4 participants