Browser and install GUI for cookiecutter templates

βŒˆβŒ‹ βŽ‡ branch:  cookiedough


Artifact [b00ab1dabd]

Artifact b00ab1dabd8c34e132f84bcbe8de351de91732db93a27b3c65f46ea6db6d502c:

Wiki page [improve] by mario 2021-03-23 09:05:48.
D 2021-03-23T09:05:48.324
L improve
N text/x-markdown
P a25fb2e3b8b77932e0dd3e9ce77ea12ade9c019909eb91940827928d12dcabdd
U mario
W 2331
### Improve your cookiecutter.json

cookiedough accepts some additional fields from `cookiecutters.json`. This
helps both the parameter input, as well as grouping, search and scoring/sorting
of entries.

Currently following options are recognized:

| Where | Name | Usage |
|-------|------|-------|
| `cookiecutter.json` | `_api` | Override the category/language (could be an app name, e.g. `flask`) |
| `cookiecutter.json` | `_keywords` | Add extra search keywords/tags (comma/space-separated string) |
| `cookiecutter.json` | `_requirements` | Build dependencies (a JSON list), for example `["poetry", "pipenv", "pluginconf"]` |
| `cookiecutter.json` | `_license` | License of the cookiecutter template files. Ideally ought to be "PD" or "CC0". If attribution/academic licsense ("MITL" or "BDSL"), the template should note itself in the generated README or CREDITS, etc. -- **Note**: license of the cookiecutter repository (that's what the GH API yields) can/should divert from the license of the actual template files. |
| `README.*` | markdown | Describe all template variables, using a "❙`varname`❙Explanation...❙" table |

For example:

     {
         "project_slug": "base-name",
         "_api": "django",
         "_keywords": "make-whl, xdg, pytest, mkdocs",
         "_license": "CC0",
         "_requirements": ["poetry", "pep517"]
     }

Whereas your README should contain explanations for template vars:

     | Variable       | Explanation ...                        |
     |----------------|----------------------------------------|
     | `project_slug` | basename for created project directory |
     | `proj_license` | ...                                    |


### Why "scoring"?

Ordering just alphabetically or by github stars isn't all that useful. Stars
are simply accrued for older projects. It's often just bandwagon voting even.

Instead cookiedough takes multiple properties into account, and somewhat
weighs them against each other. Average projects are favoured, and some
contents rewarded. It's not a huge influence, but hopefully brings more
contemporary templates to the top.

See [settings](wiki/settings) or [cookiedough/update.py](file/cookiedough/update.py)
on how the default scoring works. (This is going to be come more configurable.)


Z 4d156832182ae976a05cf04449c30b92