Poison import if Qiskit 1.0+ is detected #11617
Conversation
This uses `importlib.metadata` to search for installations of Qiskit 1.0 at runtime, and poison the import if one is detected. The two packages are incompatible in a way that we cannot express to `pip` without having poisoned the `qiskit-terra` package as a whole, which is something we're less willing to do in order to keep it easier to install old versions of Qiskit-dependent software, and to keep the Qiskit 1.0 packaging story clean for the coming years. It is not generally expected that a user specifically attempting to install Qiskit 0.45/0.46 will accidentally install Qiskit 1.0 as well. The intention of this poisoning in the "stable" branch is so that the case that a user installs Qiskit 1.0, but either also includes an old package with a dependency purely on `qiskit-terra`, or runs a subsequent `pip install` command whose version resolution causes `qiskit-terra` to become installed. In both these cases, it could be the case that the `import qiskit` command finds the `qiskit-terra` `__init__.py` file, and so any error we also place in Qiskit 1.0 would have been skipped.
|
One or more of the the following people are requested to review this:
|
|
How does this relate to: #11230 the plan we were going with before was to warn on import |
|
It's largely orthogonal to #11230 (which I'd forgotten about) - this PR fails the import if a |
jakelishman
added
on hold
|
I've marked this as "on hold", because we're planning to move ahead with it, but to include a link to a migration guide with more detail in the error message first. |
|
I've added a shortlink to the message which will work soon, but is blocked on Qiskit/documentation#710 being deployed. |
|
Qiskit/documentation#710 should be merged and live now before any release would actually land. |
releasenotes/notes/qiskit-1.0-incompatibility-9ad22472837837d8.yaml
Outdated
Show resolved
Hide resolved
releasenotes/notes/qiskit-1.0-incompatibility-9ad22472837837d8.yaml
Outdated
Show resolved
Hide resolved
| pass | ||
| else: | ||
| _major, _ = _qiskit_version.split(".", 1) | ||
| _suppress_error = os.environ.get("QISKIT_SUPPRESS_1_0_IMPORT_ERROR", False) == "1" |
There was a problem hiding this comment.
Do you think this should be documented anywhere? We do have: https://docs.quantum.ibm.com/start/configure-qiskit-local#environment-variables for env variables, but this seems esoteric and dangerous enough that it's probably not worth putting there.
There was a problem hiding this comment.
It's at the very very bottom of https://qisk.it/packaging-1-0, and in some ways I was deliberately trying to obfuscate it because I don't want people to use it. It's only intended as a relief valve if I've made a mistake in this PR.
I thought people who know enough to use it safely are likely to check the source code to see what checks it's doing before raising the error, in which case they'll see the envvar.
Co-authored-by: Matthew Treinish <[email protected]>
Summary
This uses
importlib.metadatato search for installations of Qiskit 1.0 at runtime, and poison the import if one is detected. The two packages are incompatible in a way that we cannot express topipwithout having poisoned theqiskit-terrapackage as a whole, which is something we're less willing to do in order to keep it easier to install old versions of Qiskit-dependent software, and to keep the Qiskit 1.0 packaging story clean for the coming years.It is not generally expected that a user specifically attempting to install Qiskit 0.45/0.46 will accidentally install Qiskit 1.0 as well. The intention of this poisoning in the "stable" branch is so that the case that a user installs Qiskit 1.0, but either also includes an old package with a dependency purely on
qiskit-terra, or runs a subsequentpip installcommand whose version resolution causesqiskit-terrato become installed. In both these cases, it could be the case that theimport qiskitcommand finds theqiskit-terra__init__.pyfile, and so any error we also place in Qiskit 1.0 would have been skipped.Details and comments
I will say that I don't love the idea of poisoning a package by any stretch, but given all the problems we've seen where people have inadvertently been installing broken environments while trying to test Qiskit 1.0, I think this is the pragmatic solution.
The only case of false-positive poisoning I've been able to find is very developer-centric:
qiskit-terra0.45.x (this commit) is installed by any means, and theqiskitmetapackage is either not installed, or installed but not editable in a way that overwrites the installations of step 1qiskit.egg-infodirectory that gets dropped bypip install -e .from step 1 before anydist-infooregg-infodirectory of the old qiskit metapackage in the meta path (such as if the session is launched from the repo root).If all those criteria are met, it's possible for an incompatible
qiskit.egg-infoto be in the meta path without the actual Qiskit 1.0 code being in the import path, in which case the package will emit a false positive import error. edit: the only way I can think to get a false negative is if somebody manually deletes stuff out ofsite-packageswithout usingpip uninstall, and that's not something we need to guard against.That possibility was enough to scare me, so I threw in a
QISKIT_SUPPRESS_1_0_IMPORT_ERRORenvironment variable, that can be set to1to override the error.See #11618 for the companion PR on main.