Revise handling of package metadata and build-system

This MR addresses some housekeeping on the package-level:

1. Switch from a pure setup.py build to a PEP517/518 compatible system using setup.cfg and pyproject.toml
2. Set package-wide defaults for flake8 and pytest
3. Add a gitignore file

assigned to @m300575

added 13 commits

• 2c7c56eb...29a519cc - 7 commits from branch m219063:main
• fca3161c - Add gitignore file
• 705dc36e - Switch to setup.cfg and pytproject.toml
• 5135ac1d - Use black-compatible configuration for flake8
• e01744d7 - Add pytest to requirements.txt
• 372f6687 - Enable doctests by default
• 42cc04fd - Define package version in pacakge source

Compare with previous version

For some reason this seems to hang on the 'Checking pipeline status'. I will check tomorrow to see if this is a system thing, or somehow the CI/CD is broken?

@m300575 this still hangs in the 'checking pipeline status' Let's discuss when you are back.

Ah, I believe I know what's happening... This is an issue related to gitlab's history of being more branch-and-merge based in stead of fork-and-pull based (as in github).

The problem is, that Lukas' fork is not publicly visible and for that reason, the pipeline executor of Bjorn's project is not able to fetch the commits which are in Lukas' (private) fork. Thus the pipeline is stuck. Ways to solve this are:

• make Lukas' repo public
• re-submit the changes to a branch within Bjorn's repository and re-create the Merge Request from there.

On github, the fork model usually works fine, because forks tend to be public, but on gitlab, the use of private repositories often renders the access rights across repositories difficult. These issues are enhanced due to gitlab's history, which initially didn't have any support for forking (and thus still calls the requests merge requests instead of pull requests).

merged

mentioned in commit 9fb0e244