-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Warn on import failures within optional dependencies #11522
Conversation
This distinguishes the case of "failed to find an optional dependency" from "found the optional dependency, but it failed to import" within the lazy testers. Now, a warning containing the import failures will be shown to users, rather than silently treating the dependency as missing. This occurred recently when a PR caused an import failure in Aer, which the CI suite failed to detect because the optional-dependency checkers allowed the test suite to pass regardless. Note that this commit alone won't reliably cause the test suite to fail on a failed import because: 1. this only emits a warning, not an exception (by design). 2. the `unittest` decorators are evaluated during test discovery, which happens before we activate our increased warning filters. This commit also unifies the now two Qiskit-specific warnings (the other being `QPYLoadingDeprecatedFeatureWarning`) with a common `QiskitWarning` subclass, much as we do for `QiskitError`. This gives us a convenient way to globally deny these errors during CI runs, without turning _all_ `UserWarning`s into errors, which we're not ready to do yet.
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 7463946793Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for this fix!
Edit: Oh, actually it seems there are some new warnings raised upon sklearn
imports...
Ha - nice true error on this PR. We have a couple of optionals that drill into subpackages, and the handling I put in to detect whether it's a |
Certainly an improvement to have a distinction! I'm sure there's a historical reason for this, but why is |
Kevin: do you mean why is the second on derived from If so: when Elena added |
From offline discussion with Kevin: the question was actually along the lines of "why do we make it a warning instead of an error if an optional is found but fails to import?". The answer is that in a few cases, Qiskit only uses the optionals as accelerators and not as hard requirements. Examples of this are in the generation of approximation tables for the Solovay–Kitaev algorithm or in the The idea is that the warning triggers, then if the optional is required, a regular |
There was a problem hiding this 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.
I'll wait to hit merge in case @Cryoris wants to take another look.
* Warn on import failures within optional dependencies This distinguishes the case of "failed to find an optional dependency" from "found the optional dependency, but it failed to import" within the lazy testers. Now, a warning containing the import failures will be shown to users, rather than silently treating the dependency as missing. This occurred recently when a PR caused an import failure in Aer, which the CI suite failed to detect because the optional-dependency checkers allowed the test suite to pass regardless. Note that this commit alone won't reliably cause the test suite to fail on a failed import because: 1. this only emits a warning, not an exception (by design). 2. the `unittest` decorators are evaluated during test discovery, which happens before we activate our increased warning filters. This commit also unifies the now two Qiskit-specific warnings (the other being `QPYLoadingDeprecatedFeatureWarning`) with a common `QiskitWarning` subclass, much as we do for `QiskitError`. This gives us a convenient way to globally deny these errors during CI runs, without turning _all_ `UserWarning`s into errors, which we're not ready to do yet. * Suppress unnecessary lint warnings * Fix warning when failed import is parent package
Summary
This distinguishes the case of "failed to find an optional dependency" from "found the optional dependency, but it failed to import" within the lazy testers. Now, a warning containing the import failures will be shown to users, rather than silently treating the dependency as missing.
This occurred recently when a PR caused an import failure in Aer, which the CI suite failed to detect because the optional-dependency checkers allowed the test suite to pass regardless. Note that this commit alone won't reliably cause the test suite to fail on a failed import because:
unittest
decorators are evaluated during test discovery, which happens before we activate our increased warning filters.This commit also unifies the now two Qiskit-specific warnings (the other being
QPYLoadingDeprecatedFeatureWarning
) with a commonQiskitWarning
subclass, much as we do forQiskitError
. This gives us a convenient way to globally deny these errors during CI runs, without turning allUserWarning
s into errors, which we're not ready to do yet.Details and comments
I think, in a follow-up PR, we ought to move the major warning filters (
error::DeprecationWarning
anderror::qiskit.exceptions.QiskitWarning
) intotest.python.__init__
with:so that the top-level defaults are set up in the recommended Python way before test discovery. This would let us fail the test suite if an optional has been installed but fails to import, without making the test suite dependent on what order the test cases happen to run or discover.
(It's possible that turning on deprecation warnings as errors during
qiskit
import might cause us some problems or require us to rewrite small parts of the test suite for old modules to delay the imports, but I think that might be a good thing.)For example, if this PR is applied on top of #11488 using Aer 0.13.1, which will fail to import, the behaviour of trying to use the failed optional import now looks like this:
Previously, it would just silently behave as if Aer wasn't installed at all.