Replace qiskit metapackage with qiskit-terra#11271
Conversation
|
One or more of the the following people are requested to review this:
|
qiskit metapacakge with qiskit-terraqiskit metapackage with qiskit-terra
0a99562 to
86c9ec7
Compare
Pull Request Test Coverage Report for Build 7009157389
💛 - Coveralls |
|
Ah, this cannot succeed until we can use Aer 0.13, because Aer 0.12.2 still has an old dependency on |
86c9ec7 to
541143e
Compare
This commit completely removes the concept of the `qiskit-terra` package
from Qiskit main. The hitherto metapackage `qiskit` is promoted to be
the concrete code package.
This is a completely breaking change for packaging purposes for users,
as there is no clean upgrade path from `qiskit-terra` to `qiskit`; PyPI
and pip do not give us the tools to mark that the former obsoletes and
supersedes the latter. We intend to follow this PR with a technical
blog post somewhere explaining the changes, how users should adapt
("to install Qiskit 1.0, you must start a new venv"), and why we needed
to do this.
The "why", in part, is:
- the metapackage legacy causes awkward upgrade paths on every release;
some packages still depend on `qiskit-terra`, some on `qiskit`, and
pip will happily make those two get out-of-sync when upgrading a
transitive dependency with only a warning that users are used to
ignoring.
- with the 1.0 release, we (believe we) will have some leeway from users
to make such a breaking change.
- having the metapackage split makes it difficult for downstream
projects and developers to test against `main` - they always must
install both `qiskit-terra` and `qiskit`, and the latter has no
meaning in editable installs, so needs re-installing after each
version bump. Problems surrounding this have already broken CI for
Qiskit, for at least one internal IBM repo, and at least my dev
install of Qiskit. This could be improved a bit with more education,
but it's still always going to increase the barrier to entry and make
it much harder to do the right thing.
We will not publish any 1.0 or above version of `qiskit-terra`. All
dependents on Qiskit should switch their requirements to `qiskit`.
541143e to
2feb8f9
Compare
|
Relevant fix to Neko is Qiskit/qiskit-neko#36. |
mtreinish
left a comment
There was a problem hiding this comment.
Overall this LGTM, one tiny nit in the docs about the windows usage of venv,
| # Install Qiskit (only once). | ||
| pip install 'qiskit>=1.0' | ||
|
|
||
| On Windows, replace ``source <venv>/bin/activate`` with ``source <venv>/Scripts/activate``. |
There was a problem hiding this comment.
| On Windows, replace ``source <venv>/bin/activate`` with ``source <venv>/Scripts/activate``. | |
| On Windows, replace ``source <venv>/bin/activate`` with ``source <venv>\Scripts\activate``. |
Although I guess it really depends on which windows shell you're using it'd be <venv>\Scripts\activate.bat if you're using cmd.exe or PS <venv>\Scripts\Activate.ps1 if you're using powershell. This would work if you're using bash on windows I guess though.
There was a problem hiding this comment.
This is true, I forgot people used things other than bash-likes. Shall we do something more here? I'm not sure what to write without going too overboard - I don't really know how most Windows users interact with venv.
There was a problem hiding this comment.
When I'm debugging something on windows personally I either do it via git bash (so what you had would work) or via cmd.exe and call the activate.bat file. It often depends on what I'm debugging as either shell might be needed to reproduce an issue if it involves output or default character encoding.
There was a problem hiding this comment.
But it might be better to refer to the stdlib python docs here https://docs.python.org/3/library/venv.html#how-venvs-work
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
mtreinish
left a comment
There was a problem hiding this comment.
LGTM, thanks for the quick update.
Pull Request is not mergeable
### Summary Now that the metapackage has been removed in Qiskit/qiskit#11271, we should be able to run the daily cron jobs against `qiskit` and not `qiskit-terra`.
In Qiskit#11119 we removed the use_develop flag in the tox config which was used to tell tox to use a single editable install for running a job (avoiding the need to build from sdist on every run) as part of a temporary refactoring to ensure we installed the metapackage along with terra. Now that we've standardized the packaging in Qiskit#11271 that was undone, but the usedevelop flag was not added back. This has caused tox to rebuild the package from sdist on every run even if there are no code changes. This commit restores the missing option to fix this.
…y#1329) ### Summary Now that the metapackage has been removed in Qiskit/qiskit#11271, we should be able to run the daily cron jobs against `qiskit` and not `qiskit-terra`.
…y#1329) ### Summary Now that the metapackage has been removed in Qiskit/qiskit#11271, we should be able to run the daily cron jobs against `qiskit` and not `qiskit-terra`.
* Unwrap the `Tensor` objects from Qiskit Nature as necessary Fixes #406 * Revert "Temporarily remove Qiskit Nature from dev version tests (#407)" This reverts commit 88e2195. * `unfold` the `S8Integrals` * Install qiskit only, not qiskit-terra See Qiskit/qiskit#11271. * Unpin qiskit-nature We'll probably also need to bump the version to 0.7 or higher, but let's do that once the code is ready. * Update forging to support Qiskit 1.0 and Nature 0.7 * Remove serverless tutorials * Update ruff config * Ignore forging tutorial 1 * Update qiskit readme shield. Update dev version of Qiskit to point to main branch * Move ruff changes out of this PR * Remove 0.46 from dev version testing * Update path to qiskit TwoQubitWeylDecomposition * Use 0.46 targets until 1.0 is released. * Get all tests passing by removing problematic test modules * ruff * Bump rustwork version to be compatible w Qiskit 1.0 * Bump dev version to 1.0 from 0.46 * Bug in dev workflow * Remove do_while from PassManager used to remove resets * Fix notebooks * Put do_while back * Fix recursion error with forging * Dont ignore forging tutorial * Install Nature from pypi * Make compatible with 0.46+1.0 * .github/workflows/test_development_versions.yml * Bug in cutting_experiments * Use DoWhileController * Fix impmort of DWController * Bump min qiskit version * bump max vers --------- Co-authored-by: Jim Garrison <garrison@ibm.com> Co-authored-by: Jim Garrison <jim@garrison.cc>
Summary
This commit completely removes the concept of the
qiskit-terrapackage from Qiskit main. The hitherto metapackageqiskitis promoted to be the concrete code package.This is a completely breaking change for packaging purposes for users, as there is no clean upgrade path from
qiskit-terratoqiskit; PyPI and pip do not give us the tools to mark that the former obsoletes and supersedes the latter. We intend to follow this PR with a technical blog post somewhere explaining the changes, how users should adapt ("to install Qiskit 1.0, you must start a new venv"), and why we needed to do this.The "why", in part, is:
the metapackage legacy causes awkward upgrade paths on every release; some packages still depend on
qiskit-terra, some onqiskit, and pip will happily make those two get out-of-sync when upgrading a transitive dependency with only a warning that users are used to ignoring.with the 1.0 release, we (believe we) will have some leeway from users to make such a breaking change.
having the metapackage split makes it difficult for downstream projects and developers to test against
main- they always must install bothqiskit-terraandqiskit, and the latter has no meaning in editable installs, so needs re-installing after each version bump. Problems surrounding this have already broken CI for Qiskit, for at least one internal IBM repo, and at least my dev install of Qiskit. This could be improved a bit with more education, but it's still always going to increase the barrier to entry and make it much harder to do the right thing.We will not publish any 1.0 or above version of
qiskit-terra. All dependents on Qiskit should switch their requirements toqiskit.Details and comments
We will be accompanying this change with a blog post with more information, and issuing warnings from Qiskit 0.46 about the upcoming change as well.