-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Disable pylint's import-error #8973
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
Conversation
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage.
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 3299725393
💛 - Coveralls |
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be _effectively_ losing coverage. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Summary
This pylint rule has a tendency to be overzealous when we're dealing with optional packages that we don't require to be installed, with compiled modules, and with packages which dynamically mutate the Python path look-up. Overall, it was giving far more false positives than anything else, and a failure-to-import should be abundantly obvious from a standard test run, so we shouldn't be effectively losing coverage.
Details and comments
With the work in #8967 moving to do more testing of the no-optionals paths, and to make a cleaner split between "optional package" and "development package", the additional pain pylint is causing with its overzealous
import-error
makes it more worthwhile to remove now. Python importability cannot generally be determined statically, despite what pylint tries.