uidata.json structure

The included cookiecutter database is based upon an extraction from GitHub, filtered, and restructured for easier UI application. Entries typically contain:

"vnd/pkg": {
    "name": "vnd/pkg",
    "short": "pkg",
    "description": "...",
    "url": "https://github.com/vnd/pkg",
    "repo": "https://github.com/vnd/pkg.git",
    "homepage": null,
    "created_at": "2011-11-11T11:11:11Z",
    "updated_at": "2021-02-22T22:22:22Z",
    "size": 222,
    "stars": 2,
    "api": "lang",
    "has_wiki": true,
    "forks": 1,
    "license": "MIT",
    "tickets": 0,
    "default_branch": "trunk",
    "_disabled": false,
    "keywords": " from `_keywords` in cookiecutter.json ",
    "dir": "└── lib\n",
    "readme": "README.md contents",
    "cookiecutterjson_url": "https://raw.ghusrcnt/vnd/pkg/trunk/cookiecutter.json",
    "config": [
        {
            "type": "str",
            "name": "project_name",
            "value": "mypkg",
            "class": "cookiecutter",
            "description": " taken from README table, if any "
        }
    ]
}

Most fields are literal copies. Whereas dir is a textual transformation of the /tree list. And config a converted cookiecutter.json list. The api field is either just GitHubs detected repository language (often fairly off), or an extract from the repository name, or whatever was specified as _api in cc.json.

The "score":{} dict will be freshly recreated on startup, so is not in the template database.

config

The config field list is an upmarket version of the cookiecutter.json dict. Roughly compatible with the pluginconf structure. Albeit CD is using a custom input window anyway.

Notably the description field cannot be set other than from the README. It should contain a table listing each template variable:

 | `cc_varname` | Explanation ... |

(Seen some discussion on a cc.json 2.0 format. So this might be a temporary thing. Still useful to users, btw!)

See also how to Improve your cookiecutters.json