Use pip-compile to pin ReCirq requirements.

[PawelPamula]

Pinning the requirements required fixing versions of the following
packages: pytket-cirq==0.3 and pytket=0.5.2 due to the latest pytket
relying on openfermion~=0.11 and hfvqe relying on openfermion~=1.0.0.

Also the following requirements were added:

• pytest (for efficient test suite running)
• numpy (used in various tests but wasn't explicitly required)
• pip-compile (for automated requirements generation)

[PawelPamula]

I'm happy to discuss options other than downgrading pytket library.

[dstrain115]

Adding Matt Harrigan, since this affects more than just quantum chess. Can you look over the requirements changes?

I will be happy if this finally fixes the annoying tket issue, but I thought that had to be fixed upstream.

[mpharrigan]

Can you elaborate on what's currently broken? The CI seems to be installing the current requirements just fine

[dstrain115]

Matt, there is a tket warning whenever you install recirq.

ERROR: pytket 0.7.0 has requirement openfermion~=0.11, but you'll have openfermion 1.0.0 which is incompatible.
ERROR: pytket 0.7.0 has requirement sympy~=1.6, but you'll have sympy 1.1.1 which is incompatible.

However, I think that this PR is mainly just clean-up and bolstering the requirement.txt file by using pip-compile. Sending it your way, since this changes how the requirements.txt is generated. Maybe Pawel can elaborate more on the advantages of this clean-up.

[mpharrigan]

Yes, I've done some digging and it does indeed look like pytket pins to openfermion 0.11, which is pretty insane. The pip resolver will go back and install pytket-cirq 0.3 and pytket 0.5.2 although I didn't get a warning. Are you using the latest pip?

Pinning to these older versions is a bandaid, but I can't imagine that the older version of the package is more forwards-compatible to openfermion than the new one. We should open an issue with the pytket folks in any event.

If we use pip-compile:

1. we have to re-engineer the install_requires part of setup.py which currently reads from requirements.txt. I don't want to be setting the install-requires to highly pinned packages, see pytket problems for reference on why this is a bad thing
2. Consider introducing this to Cirq as well, as I'd like to keep in sync with how they manage dependencies. That's why I'm doing the requirements.txt parsing against my will (they do it that way).
3. We need a schedule or some sort of automation for updating the pins periodically, or we will be testing against outdated packages.

[mpharrigan]

xref CQCL/pytket-docs#39

[mpharrigan]

you can put this up in the top group of "general numeric python requirements". Along with numpy (and pandas and matplotlib) it's (or at least it was) assumed to get roped in from cirq

[mpharrigan]

FWIW they fixed the latest pytket release to not have an incompatible openfermion dependency

[mpharrigan]

I've pinned pytket "the old fashioned way" in #148 (which had some other issues too). I'm interested in pip-compile but I think it would be more impactful in Cirq

[mpharrigan]

closing following #237