Modularization (dh init)

[jgonggrijp]

Now that we have decided to keep using this cookiecutter, I'm proposing to split it into (initially) five smaller ones and wrapping those together into a Python package that can be installed from PyPI. Doing so would offer several benefits:

• Convenience: install and update using pip, execute as dh init, pick independently whether you want a backend, a frontend and functional tests.
• Maintainability: follows from the increased modularity.
• Flexibility: easier to replace sub-cookiecutters or add new ones.
• Extensibility: makes it possible to add commands other than dh init, for example for scaffolding new parts of an application that was generated before, or even for migrating an existing application to a new version of the scaffold.

The initial five cookiecutters after #1 would be the following.

• Django backend
• Angular frontend
• Backbone frontend
• Functional test suite
• Integration root directory

Like any cookiecutter, each of these will consist essentially of three parts:

1. predefined set of template variables
2. templated project directory
3. post-generation script

Normally, this is also the order in which the parts are applied. First, the user is asked to confirm or override the default values of the template variables, then the project directory template is rendered and finally the post-generation script is run. However, by using the cookiecutter API, we can interlace these steps from the different sub-cookiecutters to create the same effect as when there would be one large but very flexible cookiecutter.

1. Ask the user about the integration root template variables. This includes general project properties such as name, author and license as well as independent questions of whether to include a backend (yes/no), a frontend (Angular/Backbone/none) and functional tests (yes/no).
2. Ask the user about the template variables of the chosen subprojects (backend and/or frontend and/or functest). Reuse previous answers from the other cookiecutters so the user doesn't have to answer the same question twice.
3. If more than one subproject is selected, render the integration root template. Otherwise, use the result of step 4 as the root directory.
4. Render the template(s) of the selected subproject(s) and run the corresponding post-generation script(s).
5. Run the post-generation script of the integration root if applicable.

There are some details with regard to having a bootstrap.py in each sub-cookiecutter and factoring out common functionality such as the Command class and Git setup. I will go into these details when we decide to follow up on my proposal.

[jgonggrijp]

Mentioning @BeritJanssen and @oktaal because I just realized you aren't watching this repository.