Adding new templates

Adding new templates is one of the major improvements to qube, which is why we are dedicating a whole section to it. Please note that creating new templates is a time consuming task. So be prepared to invest a few hours to bring a new template to life. The integration into qube however, is straight forward if you follow the guide below. Due to the tight coupling of our templates with all qube commands such as create, list, info, lint and bump-version, new templates require the modification of several files.

qube uses cookiecutter to create all templates. You need to familiarize yourself beforehand with cookiecutter to able to write templates, but don’t worry, it’s pretty easy and you usually get by with very few cookiecutter variables. You can start with you very first cookiecutter template and then simply see how the other existing qube templates are made and copy what you need.

The following sections will line out the requirements for new templates and guide you through the process of adding new templates step by step. Nevertheless, we strongly encourage you to discuss your proposed template first with us in public via a Github issue.

Template requirements

To keep the standard of our templates high we enforce several standards, to which all templates must adhere. Exceptions, where applicable, but they would have to be discussed beforehand. Hence, the term should.

  1. New templates should be novel. We do not want a second cli-java template, but you are of course always invited to improve it. A new commandline library does not warrant an additional template, but rather modifications of the existing template with cookiecutter if statements. However, distinct modifications of already existing templates may be eligible. An example would be to add a GUI template for a language, which does not yet have a GUI template. Templates for domains, which we do not yet cover or additional languages to already existing domains are of course more than welcome.

  2. All templates must adhere to QBiC’s version standards. For example all JVM based templates must use the QBiC’s Java version (which is currently 8).

  3. All templates should build as automatically as possible and download all dependencies without manual intervention.

  4. All templates should have a testing and possibly mocking framework included.

  5. All templates should provide a readthedocs setup (include changelog and a codeofconduct), a README.rst file, a LICENSE, Github issue and pull request templates and a .gitignore file. Moreover, a .dependabot configuration should be present if applicable. Note that most of these are already included in our common_files and do not need to be rewritten. More on that below.

  6. All templates must implement all required functionality to allow the application of all commands mentioned above to them, which includes a qube.cfg file, the template being in the available_templates.yml and more.

  7. All templates should have Github workflows, which at least build the documentation and the project.

  8. Every template should also have a workflow inside qube, which creates a project from the template with dummy values.

Step by step guide to adding new templates

Let’s assume that we are planning to add a new commandline Brainfuck template to qube. We discussed our design at length with the core team and they approved our plan. For the sake of this tutorial we assume that the path / always points to /qube. Hence, at this level we see and a folder per CLI command.

  1. Let’s add our brainfuck template information to /create/templates/available_templates.yml below the cli section.

        name: Brainfuck Commandline Tool
        handle: cli-brainfuck
        version: 0.0.1
        available libraries: none
        short description: Brainfuck Commandline tool with ANSI coloring
        long description: Amazing brainfuck tool, which can even show pretty unicorns in the console.
            Due to ANSI coloring support they can even be pink! Please someone send help.
  1. Next, we add our brainfuck template to /create/templates
    Note that it should adhere to the standards mentioned above and include all required files. Don’t forget to add a qube.cfg file to facilitate bump-version. See Configuration for details. It is mandatory to name the top level folder {{ cookiecutter.project_slug }}, which ensures that the project after creation will have a proper name. Furthermore, the cookiecutter.json file should have at least the following variables:
"full_name": "Homer Simpson",
"email": "",
"project_name": "sample-cli",
"project_slug": "sample-cli",
"version": "1.0.0",
"project_short_description": "Command-line utility to...",
"github_username": "homer_github"

The file tree of the template should resemble

├── cookiecutter.json
└── {{ cookiecutter.project_slug }}
    ├── docs
    │   ├── installation.rst
    │   └── usage.rst
    ├── .github
    │   └── workflows
    │       └── build_brainfuck.yml
    ├── qube.cfg
    └── README.rst
  1. Now it is time to subclass the TemplateCreator to implement all required functions to create our template!
    Let’s edit /create/domains/ Note that for new domains you would simply create a new file called DomainCreator.
    In this case we suggest to simply copy the code of an existing Creator and adapt it to the new domain. Your new domain may make use of other creation functions instead of create_template_without_subdomain, if they for example contain subdomains. You can examine create/ to see what’s available. You may also remove functions such as the creation of common files.
    If we have any brainfuck specific cookiecutter variables that we need to populate, we may add them to the TemplateStructCli.
    Our brainfuck templates does not have them, so we just leave it as is.
    For the next step we simply go through the CliCreator class and add our brainfuck template where required. Moreover, we implement a cli_brainfuck_options function, which we use to prompt for template specific cookiecutter variables.
class TemplateStructCli(MlfcoreTemplateStruct):
    Intended Use: This class holds all attributes specific for CLI projects


class CliCreator(TemplateCreator):

    def __init__(self):
        self.cli_struct = TemplateStructCli(domain='cli')
        self.WD = os.path.dirname(__file__)
        self.WD_Path = Path(self.WD)
        self.TEMPLATES_CLI_PATH = f'{self.WD_Path.parent}/templates/cli'

        '"" TEMPLATE VERSIONS ""'
        self.CLI_BRAINFUCK_TEMPLATE_VERSION = super().load_version('cli-brainfuck')

    def create_template(self, dot_qube: dict or None):
        Handles the CLI domain. Prompts the user for the language, general and domain specific options.

        self.cli_struct.language = qube_questionary_or_dot_qube(function='select',
                                                                question='Choose the project\'s primary language',

        # prompt the user to fetch general template configurations

        # switch case statement to prompt the user to fetch template specific configurations
        switcher = {
            'brainfuck': self.cli_brainfuck_options

        self.cli_struct.is_github_repo, \
            self.cli_struct.is_repo_private, \
            self.cli_struct.is_github_orga, \
            self.cli_struct.github_orga \
            = prompt_github_repo(dot_qube)

        if self.cli_struct.is_github_orga:
            self.cli_struct.github_username = self.cli_struct.github_orga

        # create the chosen and configured template

        # switch case statement to fetch the template version
        switcher_version = {
            'brainfuck': self.CLI_BRAINFUCK_TEMPLATE_VERSION
        self.cli_struct.template_version, self.cli_struct.template_handle = switcher_version.get(
            self.cli_struct.language.lower()), f'cli-{self.cli_struct.language.lower()}'

        super().process_common_operations(domain='cli', language=self.cli_struct.language, dot_qube=dot_qube)


    def cli_brainfuck_options(self):
        """ Prompts for cli-brainfuck specific options and saves them into the MlfcoreTemplateStruct """
  1. If a new template were added we would also have to import our new Creator in create/ and add the new domain to the domain prompt and the switcher.
    However, in this case we can simply skip this step, since cli is already included.
def choose_domain(domain: str):
    Prompts the user for the template domain.
    Creates the .qube.yml file.
    Prompts the user whether or not to create a Github repository
    :param domain: Template domain
    if not domain:
        domain = click.prompt('Choose between the following domains',

    switcher = {
        'cli': CliCreator,

    creator_obj = switcher.get(domain.lower())()
  1. Linting is up next! We need to ensure that our brainfuck template always adheres to the highest standards! Let’s edit lint/domains/
    We need to add a new class, which inherits from TemplateLinter and add our linting functions to it.
class CliBrainfuckLint(TemplateLinter, metaclass=GetLintingFunctionsMeta):
    def __init__(self, path):

    def lint(self):
        super().lint_project(self, self.methods)

    def brainfuck_files_exist(self) -> None:
        Checks a given pipeline directory for required files.
        Iterates through the templates's directory content and checkmarks files for presence.
        Files that **must** be present::
        Files that *should* be present::
        Files that *must not* be present::
        Files that *should not* be present::

        # NB: Should all be files, not directories
        # List of lists. Passes if any of the files in the sublist are found.
        files_fail = [
        files_warn = [
            [os.path.join('.github', 'workflows', 'build_brainfuck.yml')],

        # List of strings. Fails / warns if any of the strings exist.
        files_fail_ifexists = [

        files_warn_ifexists = [


        files_exist_linting(self, files_fail, files_fail_ifexists, files_warn, files_warn_ifexists)

We need to ensure that our new linting function is found when linting is applied. Therefore, we turn our eyes to lint/, import our CliBrainfuckLinter and add it to the switcher.

from import CliBrainfuckLint

switcher = {
    'cli-brainfuck': CliBrainfuckLint,

Our shiny new CliBrainfuckLinter is now ready for action!

  1. The only thing left to do now is to add a new Github Actions workflow for our template. Let’s go one level up in the folder tree and create .github/workflows/create_cli_brainfuck.yml.
    We want to ensure that if we change something in our template, that it still builds!
 name: Create cli-brainfuck Template

 on: [push]


       runs-on: ubuntu-latest
           python: [3.7, 3.8]

       - uses: actions/checkout@v2
         name: Check out source-code repository

       - name: Setup Python
         uses: actions/setup-python@v1
           python-version: ${{ matrix.python }}

       - name: Build qube
         run: |
           python clean --all install

       - name: Create cli-brainfuck Template
         run: |
           echo -e "\n\n\n\n\nn\n\n\n\nn" | qube create

       - name: Build Package
         uses: fabasoad/setup-brainfuck-action@master
           version: 0.1.dev1
       - name: Hello World
         run: |
           brainfucky --file ExplodingSpringfield/

We were pleasently surprised to see that someone already made a Github Action for brainfuck.
  1. Finally, we add some documentation to /docs/available_templates.rst and explain the purpose, design and frameworks/libraries.

    That’s it! We should now be able to try out your new template using qube create The template should be creatable, it should automatically lint after the creation and Github support should be enabled as well! If we run qube list Our new template should show up as well! I’m sure that you noticed that there’s not actually a brainfuck template in qube (yet!).

    To quote our mighty Math professors: ‘We’ll leave this as an exercise to the reader.’