remove qobj backend run

[kt474]

Summary

Passing a qobj to backend.run is deprecated - removing from these test cases

Details and comments

[jyu00]

I have to disagree with this removal. Qobj is how people submit a job pretty much since the beginning, and chances are a lot of people still do it that way, even though it's deprecated. I think it'd be useful to keep some Qobj tests, especially those related to modifying Qobj header, until we're ready to remove Qobj entirely.

[kt474]

@jyu00 does the same go for #23?

[rathishcholarajan]

@jyu00 Tests are failing due to the Deprecation Warning. Any suggestions on how we can get around this if we don't want to remove the tests? Also qobj was deprecated in 0.12 and it's time to remove it according to our deprecation policy. Should we make an exception here and how much more longer should we supporting this?

[jyu00]

does the same go for #23?

@kt474 the rng code should be updated, but it lives in the qiskit_rng repo . It's a bit tricky because it already not use Qobj for jobs submitted to IBMQBackend, but it looks for the IBMQBackend class in ibmq-provider, not qiskit_ibm. Perhaps we can make this change after qiskit_ibm is released.

Any suggestions on how we can get around this if we don't want to remove the tests?

@rathishcholarajan Deprecation warnings are converted to errors in qiskit-terra's QiskitTestCase, which itself also mark some classes as "deprecation allowed". We don't use QiskitTestCase directly as it's intended for qiskit-terra only (per class doc). However, we do use ProviderTestCase, which inherits QiskitTestCase. ProviderTestCase probably shouldn't inherit QiskitTestCase since the former is meant for all providers whereas the latter for just terra. You can open an issue in qiskit-terra about this. In the meantime we can just not use ProviderTestCase. Although we should probably implement something similar that promotes deprecation warnings to errors, with our own white list.

Also qobj was deprecated in 0.12 and it's time to remove it according to our deprecation policy.

Our deprecation policy says 3 months is the minimum. It also says that for significant features, the period should be at least double that. Given the impact of Qobj removal, I'd say 9-12 months, or until QASM3 is fully supported (so we can encourage people to move to using QASM3).

[mtreinish]

@rathishcholarajan Deprecation warnings are converted to errors in qiskit-terra's QiskitTestCase, which itself also mark some classes as "deprecation allowed". We don't use QiskitTestCase directly as it's intended for qiskit-terra only (per class doc). However, we do use ProviderTestCase, which inherits QiskitTestCase. ProviderTestCase probably shouldn't inherit QiskitTestCase since the former is meant for all providers whereas the latter for just terra. You can open an issue in qiskit-terra about this. In the meantime we can just not use ProviderTestCase. Although we should probably implement something similar that promotes deprecation warnings to errors, with our own white list.

I would say create your own base test class in this package and don't use terra's at all. I want to get rid of this shared test class antipattern as it only causes headaches like this, see Qiskit/qiskit#6862. Test code should be self contained, explicit and as flat as possible because you want it to be easy to debug and figure out what it's doing when something fails. Having to look at a parent test class definition in an upstream dependency to figure out how a test works is just going to continually cause issues.

[mtreinish]

Our deprecation policy says 3 months is the minimum. It also says that for significant features, the period should be at least double that. Given the impact of Qobj removal, I'd say 9-12 months, or until QASM3 is fully supported (so we can encourage people to move to using QASM3).

While I normally support being conservative with the deprecation policy and opting for longer deprecations than shorter ones I don't think it applies here in this case. The qiskit-ibm package is new and already contains a ton of breaking api changes nobody is just going to be able to update a couple of imports in existing code and just use this package (heck not exporting it globally off of qiskit.IBMQ will probably be a breaking change for 90% of the users) I would say we should just remove all the deprecated functionality from qiskit-ibmq-provider before the initial release. If a user was calling backend.run(qobj) on qiskit-ibmq-provider that will continue to be supported until we EoL that package since I agree with the general sentiment on the deprecation and think it should probably keep working until we stop supporting qiskit-ibmq-provider. But if they move to qiskit-ibm which is essentially a new provider we should just start with a strict BackendV1 and move forward. from there.

[jyu00]

I would say we should just remove all the deprecated functionality from qiskit-ibmq-provider before the initial release.

I was debating about this. On the one hand this is our opportunity to make all kinds of breaking changes. On the other I worry that users would not want to move to qiskit_ibm if they have to make a lot of changes instead of simple find/replace. But maybe the latter isn't really an issue because we'll eventually force their hands by archiving qiskit-ibmq-provider lol

[rathishcholarajan]

Our deprecation policy says 3 months is the minimum. It also says that for significant features, the period should be at least double that. Given the impact of Qobj removal, I'd say 9-12 months, or until QASM3 is fully supported (so we can encourage people to move to using QASM3).

While I normally support being conservative with the deprecation policy and opting for longer deprecations than shorter ones I don't think it applies here in this case. The qiskit-ibm package is new and already contains a ton of breaking api changes nobody is just going to be able to update a couple of imports in existing code and just use this package (heck not exporting it globally off of qiskit.IBMQ will probably be a breaking change for 90% of the users) I would say we should just remove all the deprecated functionality from qiskit-ibmq-provider before the initial release. If a user was calling backend.run(qobj) on qiskit-ibmq-provider that will continue to be supported until we EoL that package since I agree with the general sentiment on the deprecation and think it should probably keep working until we stop supporting qiskit-ibmq-provider. But if they move to qiskit-ibm which is essentially a new provider we should just start with a strict BackendV1 and move forward. from there.

Thanks @mtreinish and @jyu00! I agree that we should remove deprecated functionality before initial release of qiskit-ibm. So will go ahead and approve this PR.

[rathishcholarajan]

@kt474 Thanks!