Consider using a constraints file for requirements specifications

[jonssonchristian]

In #22, @cubico-craig suggested it is best practice to specify the exact versions of requirements in a constraints file. I move that topic to a separate issue here.

[jonssonchristian]

Here is some background on the current setup.

Currently requirements.txt contain the base requirements, requirements-dev.txt contain the development requirements (for linting, docs build and testing tools) and requirements-erd.txt contain the additional development requirements for generating schema diagrams using the erdantic package. I split the last one out on its own, since it has some binary requirements that may not always be easy to install, to allow for a development installation of everything else where that fails.

The requirement files are all linked dynamically in the pyproject.toml file, under tool.setuptools.dynamic.

With the current setup, a user can run pip install eya_def_tools to install the python package only with the dependencies in requirements.txt and a developer can run pip install eya_def_tools[dev,erd] to install all dependencies in the three requirement files.

[jonssonchristian]

We will definitely move to defining constraints rather than exact versions for external package requirements. For an application package that is just for deployment to users and will never be imported by other packages as a library, it is fine to specify exact requirements. The eya_def_tools package is intended mainly as a library that different applications can make use of. We do not want to impose constraints on exactly what versions of all external packages those application packages need to use. That could lead to a nightmare with incompatibilities.

The challenge will be how to set the constraints. If we allow for a range of versions of external packages, we should ideally also run tests in the pipeline to cover that range. However, variations in minor and patch release variations should rarely constitute an issue.