Problem description

Currently we are using python poetry to specify which python versions are supposed to be supported in the project.
However, this doesn't say anything about the actual version of python for the development in which the project is initalized.

Proposed solution

Add a file that pyenv will pick up on with the expect python version for development.
That way we can ensure that we have the correct python version, and don't just use the currently enabled global python.

The pyproject.toml file needs some updates. For example regarding organization/author, defaults need to be entered. Perhaps other enhancements can be needed, and some general clean-up is a good idea. This issue is used to keep an overview of everything.

The actual cookiecutter project is a bit outdated and needs some updates.
This issue tracks the different relevant aspects that need to be looked at.

• Update the github workflows to the new format. Take inspiration from this repo for the new format.
• Update the pre-commit workflows. Perhaps see if all tools are still valid and check for new tools
• Check whether settings from the repo can automatically be transferred to a new repo. i.e. regarding vulnerability and secret scanning

The current readme still has a lot of superfluous text that was obtained from the fork.
In addition it can perhaps be clearer about what is needed for the initial set-up (i.e. also including pyenv installation and such).
Update the readme regarding that, as well as what this cookiecutter does and does not do, including all implicit assumptions.

Makes it easier for future development as well to check back on what are the default and which decisions are made in the cookiecutter.

Both in the repo itself, as well as in the cookiecuttter project there is still a setup.cfg with some settings. It would be nicest to have everything in the pyproject.toml to keep an easy overview. Main blocker is flake8 which does not support pyproject.toml natively. But there are modules that allow for setting the options in the pyproject.toml need to look into that.

Currently dependabot is not scanning the dependabot workflow files from the cookiecutter repo.
These files are in the cookiecutter (jinja) structure so they start with {% raw % } tags. These tags confuse dependabot.
Somehow we need to see if we can have dependabot also scan these files despite these tags.
Otherwise we need to keep them in sync manually which is suboptimal.

Add a github action to automatically update repos to this template when they're out of date using craft. See here for a general setup.

Currently linking to indvidual extensions for VSCode.
Will be nicer if there is a single link that can be clicked to set-up everything inside VSCode that is needed, installing all extensions at once.

The pre-commit dependencies are currently not version checked, dependabot does not have an option to do so.
We need to look for alternatives to keep these dependencies up to date.

Currently the dependabot checks the requirements.txt file in the doc subfolder (of the project), not the pyproject.toml file in the main project file).

Currently the test.yml explicitly specifies which python versions should be used for testing.
However, it would be better if we got this automatically from pyproject.toml. Then we would only have to set the python version in one place. Otherwise if we add/remove/update python versions we might forget to update them in multiple places and they are not in sync.

The .vscode/settings.json is intended to automatically pick up on the virtual environment that has been created.
However, a test is currently running that will ignore the setting there, for more information: https://github.com/microsoft/vscode-python/wiki/AB-Experiments

To make sure the template works properly opt out of the experiment as follows:

You can opt out of any experiment by opening the user settings.json file (View > Command Palette… and run Preferences: Open Settings (JSON)) and set the “python.experiments.optOutFrom” setting to [“All”], or to specific experiments you wish to opt out from.

VSCode supports dev containers.
This can be very handy as it ensures all tools are properly installed (such as pyenv and poetry).
However, had some problems with permissions in the past, something to look into.