Review setup.py and requirements.txt constraints

[laurentdavid]

Following #55 pull request, we started a discussion on the constraints that we should set in the respective dependencies/setup script. This needs to be reviewed in order to insure that development environment matches the test/git workflow test environment.

Abstract from the exchanges (#55 (comment)):
"
Regarding setup.py vs requirements.txt, it got this way because I added requirements.txt for the CI, and left setup.py alone on the assumption it was the distillation of accumulated wisdom, fitting a common use pattern, etc. In development I initially used direct pip installs, and now in deployment we use requirements.txt.

According to the Python canon, the two files are supposed to be different. https://packaging.python.org/en/latest/discussions/install-requires-vs-requirements/ says of setup.py (referred to as install_requires):

It is not considered best practice to use install_requires to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades.

and of requirements.txt:

Whereas install_requires defines the dependencies for a single project, Requirements Files are often used to define the requirements for a complete Python environment.

Whereas install_requires requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving repeatable installations of a complete environment.

This is the reverse of what we do: we generally have stricter pinning in setup.py than in requirements.txt.
"