qiskit.algorithms move as an independent package #44
Conversation
There was a problem hiding this comment.
Thanks! Where will the docs move to? qiskit.org/ecosystem/algorithms? That name would match how we have e.g. qiskit-nature at ecosystem/nature.
FYI we can set up redirects in cloudflare from the qiskit.org/documentation/ subpages to ecosystem/algorithms if we want.
Exactly, I was thinking of |
0012-algorithms-migration.md
Outdated
| 2. Add a dependency of `qiskit_algorithms` to qiskit-terra so that installing terra will also install the | ||
| algorithms until the deprecation period is over. [Blocker: the separate algorithms package would have to | ||
| be ready and be published ahead of terra releasing] |
There was a problem hiding this comment.
If this dependency is added to Terra, I'd recommend pinning the version using the ~= compatible release clause or its equivalent.
Co-authored-by: Luciano Bello <[email protected]>
Co-authored-by: Luciano Bello <[email protected]>
1ucian0
changed the title
* All of the old build configuration was moved under the qiskit-terra output
* The qiskit output installs the separate package under qiskit_pkg in
the source code.
- For the moment, the qiskit and qiskit-terra package versions and
build numbers do not match, but with version 0.45, they should be
synchronized.
- The qiskit output could be noarch if it were possible for conda to
support multiple outputs with an arch-specific subpackage and a
noarch package that depends on it.
* The qiskit.algorithms test was removed as qiskit.algorithms is moving
to a separate package. See Qiskit/RFCs#44.
| from `qiskit.algorithms` to `qiskit_algorithms`. The code will continue existing | ||
| in `qiskit-terra` until the deprecation period is over [Blocker: release of `qiskit_algorithms-0.1.0`, | ||
| see below]. | ||
| 2. What should we do with the algorithms migration guide? we could leave it in terra during the deprecation period, |
There was a problem hiding this comment.
Migration guides usually stay online after the deprecation period.
There was a problem hiding this comment.
This particular guide is for migrating from QuantumInstance-based qiskit.algorithms to primitive-based qiskit.algorithms. I am all for keeping guides for as long as possible, but I am not sure how to balance this with "completely decoupling qiskit.algorithms from qiskit" efforts. That is why we suggested to move this guide to the qiskit-algorithms repository (but keep the opflow/quantum instance ones in qiskit). It would stay alive but decoupled. This is also consistent with feedback that we are getting on the qiskit-ibm-runtime docs to remove qiskit.algorithms from migration guides (see Qiskit/qiskit-ibm-runtime#1032)
There was a problem hiding this comment.
At least when I remember discussing this a while ago when @woodsp-ibm brought this up the thinking was that we'll have the stable docs builds for historical releases so we can just point people to: https://qiskit.org/documentation/stable/0.44/migration_guides/algorithms_migration.html and not worry about having to keep the guides in source form forever.
There was a problem hiding this comment.
As we do not have older versions of docs published in the apps what we have been doing there, once a migration guide no longer can be run/built from main is to convert it as a rst file so it gets included but its content is no longer executed. I had been thinking that if the guide was wanted to be kept/publihsed longer in Qiskit that potentially in main its contents just got replaced by a link to the stable published version where it existed since the older versions of the docs were kept. That seemed simpler to me and also being a link one could state that the deprecation period was over or whatever other text you wanted there.
There was a problem hiding this comment.
With the exception of one copy paste error inline I think this is fine to merge. There are still some small questions/musings and steps that diverged a bit from what we implemented but that's fine for an rfc as it's a document of a plan not necessarily everything that was implemented. But not worth blocking or changing at this point since the rfc is basically all implemented at this point
Co-authored-by: Matthew Treinish <[email protected]>
In an attempt to inform and coordinate the move of the algorithms repo, I have quickly pulled together an RFC.