Make dependencies more flexible #106
Description
Because of errors like the one reported in issue #168, I was specifying the versions for the dependencies on those old requirements.txt files that were guaranteed to work. That avoided problems like this, but it made it harder to introduce new dependencies, as conflicts could happen and we needed to figure out by ourselves, like I did for those ml_dev dependencies. Btw, PyTorch's dependencies are a whole different beast, so we might need to deal with them separately, as I did.
But since we removed the versions from most of these dependencies, we opened room for these unpredictable errors we are seeing with Dask, that are currently out of our control.
There are pros and cons for keeping the dependencies' version flexible. I would love to keep FlowCept's dependencies as flexible as possible and it would be great if FlowCept always worked fine with the latest versions of its dependencies, but since FlowCept relies on third parties' APIs to access their data, which are subject to change for every new version of its dependencies, we might need to think of a different solution.
Since it is a recurring problem, I even created a label for this. If we think of a good solution, this might solve a major pain in this project.