Skip to content

Migrate the library to Qiskit 2.0 #973

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Siddharthgolecha
Copy link

@Siddharthgolecha Siddharthgolecha commented Aug 7, 2025

Summary

Qiskit Machine Learning library currently uses Qiskit >=1.0 and <2.0 making it incompatible with the latest Qiskit Version and changes. I have attempted to migrate the library to use the latest Qiskit version.

Fixes #897 and #934

🤖 ✨ Made with the help of the Qiskit Code Assistant

Details and comments

  1. Migrated the usage of
  • qiskit.primitives.BaseSampler to qiskit.primitives.BaseSamplerV2
  • qiskit.primitives.BaseSamplerV1 to qiskit.primitives.BaseSamplerV2
  • qiskit.primitives.Sampler to qiskit.primitives.StatevectorSampler
  • qiskit.primitives.BaseEstimator to qiskit.primitives.BaseEstimatorV2
  • qiskit.primitives.BaseEstimatorV1 to qiskit.primitives.BaseEstimatorV2
  • qiskit.primitives.Estimator to qiskit.primitives.StatevectorEstimator
  • qiskit.circuit.library.ZZFeatureMap to qiskit.circuit.library.zz_feature_map
  • qiskit.circuit.library.ZFeatureMap to qiskit.circuit.library.z_feature_map
  • qiskit.circuit.library.RealAmplitudes to qiskit.circuit.library.real_amplitudes
  • qiskit.circuit.library.EfficientSU2 to qiskit.circuit.library.efficient_su2
  • qiskit.circuit.library.PauliFeatureMap to qiskit.circuit.library.pauli_feature_map
  1. Corrected the test cases to incorporate these new changes.
  2. Fixed the new usage and signatures to match Qiskit's latest practices.
  3. Removed the argument use_methods=True in VQC as it is not required anymore.

@CLAassistant
Copy link

CLAassistant commented Aug 7, 2025

CLA assistant check
All committers have signed the CLA.

@woodsp-ibm
Copy link
Member

woodsp-ibm commented Aug 7, 2025

An overall comment. The V1 primitives usage was deprecated in 0.8 release and marked for removal in 0.9. So in that regards that aspect of this PR fits with the plan as the next main release to happen would be 0.9. However the removal of the Blueprint circuit support - this was deprecated in this PR #945 which was intended to go out in 0.9 with the removal in a subsequent version. Qiskit has deprecated these Blueprint based circuits with the plan to remove them in 0.3 3.0. So they do not need removing to support 0.2 2.0 indeed removing them, without even having released 0.9 with them being deprecated (as done in #945) would be a breaking change for end-users with no notice at all. Hence that aspect of this PR is really too soon.

from qiskit.quantum_info.operators.base_operator import BaseOperator
from qiskit.transpiler.passmanager import BasePassManager
from qiskit_aer.primitives.sampler import _circuit_key
Copy link
Member

@woodsp-ibm woodsp-ibm Aug 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This (line 26 there above) adds a dependence to qiskit_aer which currently ML does not have. Sure it's supported but it's down to the user if they optionally install/use it or not. This import/use of the function will require it. What was done in qiskit algorithms was just to copy over the former circuit key function https://github.com/qiskit-community/qiskit-algorithms/blob/d84bd401bdcba99b8a1c07a8a9e8859097ec3abf/qiskit_algorithms/utils/circuit_key.py#L45 to the repo and use that instead. (Yes it was discussed to remove usage of this too if that were possible/practical...)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But would rewriting the logic in every library makes sense? Wouldn't it be a better choice to import from one single source?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, its better not to have a local copy - but with it being dropped from qiskit I could see it being dropped from qiskit_aer too, and as I said the ML library does not have a dependency on aer so its not installed by default - CI installs it here so it will work here as tests are done with aer, But for an end user its optional whether they choose to want to install/use aer and without it that circuit key import will fail. Ideally code should move away from using it at all since circuits are mutable - but maybe for what its used for here its ok.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll reimplement this function in the library itself. I think that solves our concerns for now.

numpy>=2.0
scipy>=1.4,<1.16
scipy>=1.16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note there is another PR that was fixing tests to work with 1.16 i.e. #966. Maybe this fixes thing too - I do not know. Either way I made a comment in that PR when it was changed like this to start with #966 (comment)

This cannot stay like this, > 1.4 I think was ok as in Python 3.9/3/10 1.16 does not exist (has a >= 3.11 requirement). If you want to bump the min to say the prior version that still works with 3.9/3.10 that should be fine.

Copy link
Author

@Siddharthgolecha Siddharthgolecha Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for letting me know. I didn't realize that the min py version for 1.16 is 3.11. It makes sense if we don't want to bump the min py version of the library as a whole. Make these many changes in one single lib version would not be a great idea. I'll keep this back to 1.14.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 1.16 was also excluded as you can see as there are failures that occur with that which another PR was trying to sort out. 1.4 was the minimum version that ML is known to work with - there is no reason to require a user, that might already have scipy installed to force them to a newer version unless ML really requires that e.g. uses some newly introduced function in which case updating this would be wanted. But not now I think. The only thing that we would like to happen is the < 1.16 is removed to allow even the very latest versions once the issues with it are taken care of by that PR I referenced above.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I'll revert back this change 👍

@Siddharthgolecha
Copy link
Author

So they do not need removing to support 0.2 indeed removing them, without even having released 0.9 with them being deprecated (as done in #945) would be a breaking change for end-users with no notice at all. Hence that aspect of this PR is really too soon.

Hi, do you mean that since BlueprintCircuit is just deprecated in the 2.1 and will be removed completely in 3.0, we should not remove it or its related components? Like ZZFeatureMap and RealAmplitudes?

@woodsp-ibm
Copy link
Member

Hi, do you mean that since BlueprintCircuit is just deprecated in the 2.1 and will be removed completely in 3.0, we should not remove it or its related components? Like ZZFeatureMap and RealAmplitudes?

Yes they were deprecated in Qiskit 2.0 and planned to be removed in 3.0 (my bad I typed 0.2 and 0.3 above - I edited the original comment. As ML has not been released with the update that deprecates their use itself we do not want to remove Blueprint circuits from being used at this time - rather in a future version to allow users to change/update any existing code they may have that uses these rather than it just breaking if their support was removed. The next version of ML to be released, i.e. 0.9, would include their deprecation as was added by #945. So far that code only exists here in the repo until such time as a new release is made that includes it in the official version (i.e 0,9). Is that clearer. Removing the V1 primitive support is ok, V2 support was added in the last release (0,8) so both were supported by ML but V1 usage was deprecated - giving time for people to switch their code to V2. So the plan was to remove V1 support for the 0.9 release. So you see the pattern, support both old way, but deprecated, and the new way for a period of time to allow users time to changeover without breaking their code,

@Siddharthgolecha
Copy link
Author

As ML has not been released with the update that deprecates their use itself we do not want to remove Blueprint circuits from being used at this time - rather in a future version to allow users to change/update any existing code they may have that uses these rather than it just breaking if their support was removed.

I agree, we don't want to break the user experience for the users. But what I am trying to say is that even if we remove these, it won't break the user experience. Let's take one example, the function utils.adjust_num_qubits.derive_num_qubits_feature_map_ansatz takes in num_qubits, feature_map, ansatz and use_methods as parameters. I have simplified the logic by removing the use_methods and usage of BlueCircuit derived classes. But I have not removed BlueCircuit usage completely. The QNNCircuit class still exists and I have not made any change to that. So, I think the changes I have made regarding that do not impact the user experience and the code. However, I would like to hear your thoughts on this as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migration to qiskit 2.0 and integration testing
3 participants