bumped versions of dependencies

[dkeeney]

First cut at bumping the versions of all dependencies

[dkeeney]

This PR addresses Issue #975
Do not merge!
This iteration of the PR has a problem on Windows in py unit tests at bindings/py/tests/regions/network_test.py line 378
Testing with Visual Studio 2022 and Python 3.9.6

[dkeeney]

Should we bump the versions on the Python dependencies as well?

[ctrl-z-9000-times]

I don't think we need to bump the python dependencies because IIRC "setup.py" will automatically install the latest version.
It should be checking pypi.org to get the latest versions of everything.

[dkeeney]

ok, that is why I asked. It's just that requirements.txt specifies a version. I don't know if that just specifies a minimum or locks it to that version.

[dkeeney]

This pickle problem is not going to be easy to find.
What I need is the ability to capture the C++ log (stdout) when it is ran from python. If I had that I could turn on some tracing and see how far it got before it crashed.

I thought we had something to do that but it has been so long ago and my 75 year-old brain is not recalling it.

[ctrl-z-9000-times]

Ok, I just checked it. Yes, our "requirements.txt" only specifies minimums.

---

The python test cases will display anything printed to std-out when they fail, its part of the test summary that's printed at the end.

The place where the error is generated, binascii, is part of the python std-lib and it appears to be a compiled C extension, so i think it's going to be very difficult to modify that code with tracing statements.

I assume that this bug is the result of updating the cereal library?
Maybe we could update to an older version or update everything except cereal, and see if the problem persists.

[dkeeney]

backing out cereal had no effect.
I put back cereal to latest and backed out pybind11.
It fixed the serialization problem but caused a different error in anomaly_likelihood_test.py line129 and 81
Thinking it might be a timing problem I ran it a second time and it was the same result.

I will push this and you can take a look at it.
In the mean time I will try some other combinations.

[ctrl-z-9000-times]

error in anomaly_likelihood_test.py line129 and 81

That's my fault. I think I introduced those errors when I backed out a change to the anomaly likelihood code.
I'm not entirely sure what to do about those test failures.
The comments describing those 2 testcases do not exactly match what the test actually does.
I think I can fix those tests by setting the anomaly detection threshold to a different value for each?

[ctrl-z-9000-times]

I retested this (linux, release mode) and it all passes except for the 2 failing anomaly likelihood tests. This all looks good to me!

[dkeeney]

Ok, the changes to the dependency versions is now in master.
Thanks @ctrl-z-9000-times and finnoshea for your help on this one.