Remove version footers at tutorials

[rraymondhp]

Description

The old release of qiskit-sdk-py is not compatible with the latest API.

Your Environment

• QISKit version:
• Python version:

[rraymondhp]

Replace %run "../../version.ipynb" at the bottom of each tutorial with:

!python --version
print()
!pip show qiskit
print()
!pip show IBMQuantumExperience
print()
!pip show numpy
print()
!pip show scipy
print()
!pip show matplotlib

[jaygambetta]

@diego-plan9 could you look at @rraymondhp suggestion for making a better version.ipnb

[rraymondhp]

@diego-plan9 I am proposing to replace the version.ipynb with this file:
https://github.com/rraymondhp/qiskit-tutorial/blob/57123039684853c4b6af4c7a51203fcabda7b052/version.ipynb

[rraymondhp]

Otherwise, we have to make sure the contents of the requirements.txt reflect what has been installed in the users' system. Otherwise, the original version checking is misleading.

[rraymondhp]

@diego-plan9 Let us discuss how to check the version of python, qiskit, IBMQuantumExperience and other required packages here. Because the tutorial uses conda env create .. and QISKitenv.yml file to install the latest packages, it does not use requirements.txt anymore.

Therefore, for version checking we should think of other way than listing the contents of the requirements.txt.

[diego-plan9]

I think the core question is what should the footer version contain. The original idea was that it would be a "single, static source of truth when it comes to the versions needed to run the tutorials", listing them based on the requirements of qiskit dependency specifications (and always producing the same list, regardless of the environment or the setup where the user run the notebook). So it is basically "static text", that was meant to be updated whenever a new release of qiskit was issued and the tutorials tweaked to that particular version (and Ii fully agree that "updating" part has proven to be problematic).

With your proposed implementation, the footer would contain information fetched from "the user's environment", or at least "from the specific user that submitted the PR for a specific tutorial". If that is the intent (for example, having someone with a trusted setup always recreate that information), it's fine, but I think it has the potential for leading to more confusion: for example, if a user with the wrong qiskit version happens to re-run version.ipynb and the information is gathered from his environment, the footer would end up containing misleading information for him. There is also a loss of information up to some extent (for example, it would include a specific version of a library rather than a range of the versions allowed).

For context, the requirements.txt file on the root folder of this repo is only used by the version footer and not by the packaging tools - it was actually the purpose of including it in the first place. It can be named anything else (as long as the .py file is updated) or included in other form, but the name was left as is since it had the added bonus of being able to hint some users into how to install the dependencies easily (ie. for those familiar with pip, for example).

[rraymondhp]

But the requirements.txt does not list the true version of qiskit used to run the tutorials. This can be problematic when asking what version the user is using to run the tutorial.

The fix is to make sure that requirements.txt always list the true version used, but I do not know how to do it.

[diego-plan9]

But the requirements.txt does not list the true version of qiskit used to run the tutorials. This can be problematic when asking what version the user is using to run the tutorial.

Yes - it would need to be updated and some measures taken to ensure they don't fall out of sync again, absolutely. But I think this is an organizational issue separate from the implementation: those measures will be needed with either approach, as long as some kind of "list of reference versions" are needed (in the other implementation, ensuring that it is recreated by a user with the right versions installed - it is doable, but I'm worried about fetching the information from the environment will end up being more error prone).

This said - I actually wonder if the version footer does really serve a purpose now that the tutorials are going to have a more streamlined installation, with a single branch and targeting a single version? Except for qiskit, all the allowed versions of the dependencies should be automatically checked and installed properly during the installation of qiskit itself (unless something goes very wrong), and we might be able to make use of version pinning in QISKitenv.yml if needed. Maybe the potential advantages of the version footer are more diluted now, and it would be enough with just listing qiskit 0.4.12 and no other dependencies?

[diego-plan9]

Following up after some private conversations - it seems just removing the version footer (and instead adding a mention of just the qiskit version in the Reference section of the main README (or/and in the reference/README.md) would be enough!

[rraymondhp]

Thanks Diego!
I will do that and after confirming all version footers have been removed, I will close this issue.

[jaygambetta]

@rraymondhp can you do this week and close this issue.

[attp]

I've addressed this in Pull Request #189 and have asked @rraymondhp to review.

[rraymondhp]

@jaygambetta I will finish this within this week.
Thanks @attp