Remove qubits as an input from TomographyExperiment

[msohaibalam]

The qubits field is a redundant input to TomographyExperiment, in the sense that measure_observables never uses it for anything at all. This PR removes this extraneous input.

[jonward-rigetti]

🌴 wasn't ready for this change @msohaibalam @karalekas

[msohaibalam]

@jonward-rigetti I can create a PR for 🌴to reflect these changes very soon. Is there anywhere else you can think of where pyquil: operator_estimation is used? The only other place I'm aware of is rigetti/forest-benchmarking

[jonward-rigetti]

I'll take care of the 🌴 -side fix, but this does make me wonder about how to avoid this in the future.

[notmgsk]

Test internal tools against pyQuil master?

[msohaibalam]

I'll take care of the willow-side fix, but this does make me wonder about how to avoid this in the future.

I think the best way is to create simultaneous PRs. There will be a few more changes coming very soon to pyquil: operator_estimation. I can create the relevant corresponding PRs in forest-benchmarking and can tag you so you know to create the appropriate change in willow (or I can take care of that too, either way)

[jonward-rigetti]

That sounds reasonable, but we should also have a CI solution, e.g. triggering a new 🌴 master build when pyquil master gets updated.

[notmgsk]

Should probably do the same for 🐦 etc

[caryan]

We could also not make breaking API changes on a point release. We could have kwarg'd qubits to default to None and if it was passed in logged a warning saying we're that on a future release we will no longer use this parameter.

[jonward-rigetti]

Yes, we need to follow a deprecation path for signature changes.

[blakejohnson]

I will echo @caryan's comment. This change should trigger a major version bump in pyquil since it modifies a public API.

[msohaibalam]

@blakejohnson @caryan @astaley @karalekas This and other changes are necessary before we can more widely advertise this part of the API, and it starts getting used by external users. There was an internal discussion on the pros and cons of changing parts of pyQuil: operator_estimation, and the conclusion was to make the necessary changes, create docs, examples etc. as regular PRs in pyQuil, and create appropriate updates to any libraries that we internally use. If this conclusion needs to be revisited, I'm all ears. But I don't think it's a good idea to not make the changes that we had decided to make, or go through several hoops to make it "backwards compatible", since the work on pyquil: operator_estimation has not yet finished. Could it be a good compromise to pin the version(s) of forest-benchmarking and 🌴 to older versions of pyquil, and bump their versions up, and create the necessary updates, once the work on pyquil: operator_estimation is complete?