Remove extras installers for apps modules and experiments.

[blakejohnson]

Code change to accompany #1751. Removes apps module extra installers from setup.py.

[blakejohnson]

We have to accept this disruption because these other packages (with the exception of qiskit-experiments) are no longer receiving active development by the core Qiskit team. So, either you let people continue to install dependencies that we don't maintain, or you force them to realize that those packages aren't included in Qiskit and consciously choose to install them anyway.

[Eric-Arellano]

We have to accept this disruption

Sure, there will be disruption no matter what. But it's not binary. There are meaningful ways to reduce the disruption to users. That's valuable to keep trust in Qiskit; one of the quickest ways to burn trust is to break people's CI.

So, I am curious what you think about how we can reduce this damage of trust? What are your thoughts on the above 3 suggestions?

[mtreinish]

The working plan for doing this migration was to do it after the next big release at the end of July. That release will be marking the final "metapackage release", and as part of that large upgrade note about all the changes being made (eol for ibmq, aer no longer being included, etc) we're planning to document that release, qiskit 0.44.0, is the final release that has these extras included and document how users will need to update their potential usage of them. I think this should wait until after that release and continue on that path.

[blakejohnson]

Sounds good, @mtreinish

[javabster]

@Eric-Arellano fwiw we've been slowly trying to move people away from installing the application modules via the metapackage for a little while now (see the metapackage section of this post from a while back). And when the changes in this PR go into effect with the next big release we'll make sure to warn users in our usual blog/youtube/twitter comms

[1ucian0]

The working plan for doing this migration was to do it after the next big release at the end of July.

See https://github.com/Qiskit/RFCs/issues/41

[jakelishman]

Just for fun: technically we can emit some degree of runtime warning if we really wanted to. The trick is to make a dummy package that we upload to PyPI and add to the given extras with a no-collision name like qiskit_deprecation_check_nature or whatever. Then there's something that can be tested for at runtime (or even install time, if we're being particularly bad citizens of Python, since we only provide an sdist for the metapackage) using importlib.metadata, and it wouldn't be installed by any standard means.

[Eric-Arellano]

Given the updated plan in https://github.com/Qiskit/RFCs/issues/41, I'm going to close this so that we keep the PR list clean with only currently active PRs. We can reopen this PR when ready.

In July release, mention that optionals are going to be removed in October release In October release, remove optionals from metapackage. Make the terra and metapackage optionals, the same.

[1ucian0]

Just for fun: technically we can emit some degree of runtime warning if we really wanted to.

I'm not sure if it is worthy.

While it is hard to know how used are extras, there is no much evidence of the use of these extras. There are 6 questions in stackoverflow that mention qiskit installation: one of them mentioning visualization, nothing about the rest. Similarly, in stackexchange, 12 questions with pip install qiskit, none of them using extras. The only entry I found in google (besides installation instruction) is this one for nature, these two for optimization, one for machine-learning, and this one for finance.

I think the reason is because there is no advantage wrt to just installing the package itself. all seems slightly more used, by some tutorials and blogpost out there, but now they have their own namespace, I think is fair to assume they need their own packages.