GitLab

I am putting this up for discussion - any input is appreciated.

Core idea

The duneproject script - our user entry point for the generation of new modules - is a huge pile of bash code. In my experience, this lead to the actual template being very rarely modernized, because its definition lives inside that huge pile. This merge request completely removes the current implementation and replaces it with one that is based on an established tool and uses Jinja2 - a state of the art template engine.

What is cookiecutter?

cookiecutter is a Python project that configures projects of all sorts of languages from project templates. There are thousands of templates available on the Internet. For the purpose of this merge request, only the template dune-cookiecutter is relevant.

What are the advantages?

• The project template is an actual directory tree, whose content is written using the Jinja2 templating engine: https://gitlab.dune-project.org/dominic/dune-cookiecutter/-/tree/master/%7B%7Bcookiecutter.module_name%7D%7D The template will definitely see a lot more modernization. E.g. nobody has started adding a default CI configuration so far, although it would be super good to have something like it.
• Jinja2 templates can contain a certain amount of logic which will allow us to have the user configure the template much more than we currently do. On demand features that sound interesting: Python bindings skeleton, Doxygen documentation, have CMake build a module-specific library
• Additional logic like validation of provided configuration values can be integrated much easier
• Cookiecutter has some interesting options in itself, e.g. a user can provide global default configuration values on his machine.

What are disadvantages

• Cookiecutter is a Python project and requires installation. The MR currently checks for its availability and gives a meaningful error message.
• Although quite good, there are some missing features in cookiecutter. Looking through their issue tracker, they are all known, there even are implementations, but they generally have a very conservative progresssion speed. Some examples:
  • Template-provided Jinja extensions may make it much easier to write these templates (by hiding all the name transformations of Dune module names in custom Jinja filters): https://github.com/cookiecutter/cookiecutter/pull/1240
  • YAML files would be IMO much better than JSON files to describe the configuration: https://github.com/cookiecutter/cookiecutter/pull/1136
  • Currently, all configuration values are prompted to the user instead of having some depend on others (like only ask for documentation-specific parameters, if the documentation feature was enabled in the first place): https://github.com/cookiecutter/cookiecutter/pull/848

Open Questions

• Where is the template put?
  • In my namespace: I would only do that if this feature is turned down and only advocated as an alternative, non-supported way of configuring Dune modules.
  • A separate module somewhere in core, staging, infrastructure whatever. It has the disadvantage that calls to duneproject require Internet access (it caches though)
  • Placing it in dune-common. cookiecutter would then work with a path instead of a URL.
• While at it - what features to add. The current version is a translation of what duneproject did before, but there is room for a lot of improvements.
• Do the benefits outweight the disadvantage of depending on a Python package?

How to try

Just do the following:

python -m pip install cookiecutter
python -m cookiecutter https://gitlab.dune-project.org/dominic/dune-cookiecutter