Update about() and document latest package support

[Aaron-Robertson]

Issue Description

Latest supported versions of optional dependencies are not well documented. It is unclear which frontend version(s) to install after a user installs through pip install mitiq, but wants to use Qiskit, Pennylane, Braket, and/or PyQuil.

Proposed Solution

• Update about() to include Pennylane
• Create a function latest_supported() to parse Qiskit, Pennylane (and Pennylane-Qiskit), Braket, and PyQuil versions from dev_requirements.txt
• Add Latest Supported as a column in about() under Optional Dependencies
• Create a user warning when package versions are ahead of latest (from Andrea):

e.g. something like: WARNING: Mitiq is tested with version xxx of Qiskit. Your version is higher and may be incompatible...

• Add warning to about()
• Add warning to QPROGRAM type builder
• Add latest_supported() with output to docs under Supported Frontends

Additional References

Discussed in Mitiq meeting 04/01/22. See this thread on discord.

[Aaron-Robertson]

@andreamari label/change this issue as you see fit. As written I think it would be a good first issue.

[andreamari]

Thanks @Aaron-Robertson!

[github-actions]

This issue had no activity for 4 months, and will be closed in 2 weeks unless there is new activity. Cheers!

[jordandsullivan]

So just getting my bearings here:

1. Was some version of the latest_supported() function ever actually merged into main? It's hard to tell between the discussion in Update about() and document latest package support #1220 and Add a function in Mitiq that returns the versions of supported frontends as extracted from dev_requirements.txt #1478.

The Mitiq Read the Docs is generated by sphinx, and the supported backends section comes specifically from the README.
2. We want to get this section to display the latest ne idea would be to use the workflow from the examples (i.e. use myst-nb to convert the README.md to a jupyter notebook, run that notebook to get the output of the latest_supported() function (if indeed it was implemented). Does this seem workable?

[jordandsullivan]

@andreamari Could you help answer the above?

[natestemen]

Not Andrea, but I think I might be able to answer!

Was some version of the latest_supported() function ever actually merged into main?

Nope!

Does this seem workable?

I think it's workable, but probably not from the README as the README does not get executed like other pages in the documentation.

[jordandsullivan]

1. Why did the method not end up getting merged? Would it be straightforward to merge it now, or would a reimplementation be necessary? Again it's a little hard to tell from the various closed issues related to this one.

2. Perhaps if we linked from the README to a page within the docs that calls the latest_supported() function, that would work.

[natestemen]

Why did the method not end up getting merged?

From what I can glance from the PR (it's from before I started) and the issue (which was closed as "completed", but that may have just been because it is the default close option, as opposed to the other "close as not planned" option), it got complicated, and perhaps the value-add was not quite as great as originally estimated.

Would it be straightforward to merge it now, or would a reimplementation be necessary?

Some changes would almost definitely need to be made as it looks like the PR did not make it's way into a passing state. I don't currently love the approach of making an HTTP request to fetch the requirements, but if it's the only option then 🤷🏻.

Again it's a little hard to tell from the various closed issues related to this one.

Lemme know if there's anything in particular that's confusing and we can try to figure it out together! (live or async)

Perhaps if we linked from the README to a page within the docs that calls the latest_supported() function, that would work.

Yup, definitely! As Andrea suggested here, the Frontends and Backends page seems to make sense to demo this functionality if we add it.

[cosenal]

@jordandsullivan @natestemen Would you agree that @Aaron-Robertson's original requirement is met by #2303?

[jordandsullivan]

I would say so yes.

[andreamari]

@andreamari Could you help answer the above?

I apologize for the late reply. #1220 was a first attempt but was based on some dirty workarounds (e.g. http requests as noted by Nate) and so we decided to drop that PR.

#2303 seems a cleaner approach.