Relax install_requires constraints

Based on https://packaging.python.org/discussions/install-requires-vs-requirements/ “It is not considered best practice to use install_requires to pin dependencies to specific versions”.

We need to loosen up install_requires while keeping the CI stable. We don’t have good, documented reasons for the lower/upper boundaries. Maybe we could just pin to major versions and let the minors fly free? And then, for CI we could setup a bot that checks for updates weekly and raises a PR with an updated minor version for each requirement (with pur: https://pypi.org/project/pur/) to make sure we’re testing against the latest available versions.

Context:

• https://github.com/quantumlib/Cirq/pull/2648
• https://github.com/quantumlib/Cirq/pull/3551
• https://github.com/quantumlib/OpenFermion-Cirq/pull/352#issuecomment-513044359

[m-szalay]

The way python devs are going at this is convoluted to say the least… I cannot believe that they pulled the switch on the new dependency resolution “feature” without allowing for a reasonable override method… forking the dependency and loosen the requirements as the standard solution is… questionable. Having said that, to fix the current blocking issue, having >= + blacklist sounds good to me.

[mpharrigan]

Can we just freeze depth=1 or depth=2 of our dependency graph? I guess it technically wouldn’t be a reproducible build but it’s more than what we have now