hmd-cli-mickey 1.0.51

General purpose code generator

See also hmd-tf-mickey for specific configuration, also hmd-lib-mickey. See also NeuronSphere writing on model-driven-code generation, as this is the tool used to provide that capability across the suite.

The hmd-cli-mickey package, or just Mickey, is a CLI general-purpose code generator. It takes in one or more data files, or contexts, and uses them to render one or more templates. The contexts can be structured text in the form of JSON, YAML, or XML, and run through a simple preprocessor to allow modifications if necessary. The templates use standard Jinja syntax. They are rendered with the values from each context found, plus additional variables that can be supplied via configuration or CLI and some default variables. The rendered output will be saved relative to the repository root in which you run the command. Template paths can also include Jinja syntax to allow for dynamic paths based on contexts.

All of the actual code generation occurs within a Docker container. The CLI is merely a wrapper around pulling and running the hmd-tf-mickey container. It will pass along any necessary configuration and environment variables, as well as mounting an necessary volumes. This does mean that Docker must be installed in order use Mickey.

Installation

The hmd-cli-mickey package can be installed PyPI via Pip:

pip install hmd-cli-mickey

The CLI will pull and run a Docker image from ghcr.io/neuronsphere/hmd-tf-mickey:stable.

Configuration

Mickey relies on certain environment variables and a JSON configuration file located at ./meta-data/manifest.json in your repository.

Environment Variables

• HMD_CONTAINER_REGISTRY: the Docker container from which to pull the hmd-tf-mickey image, defaults to ghcr.io/neuronsphere

• HMD_TF_MICKEY_VERSION: the version tag of hmd-tf-mickey to use, defaults to stable

manifest.json

Mickey expects a file located at ./meta-data/manifest.json relaive to your repository root with the following structure:

{
  "name": "<name of repository>",
  "generate": {
    "example": {
      "contexts": ["ref:examples"],
      "templates": ["<name of repository>/examples/"]
    }
  },
  "contexts": {
    "examples": ["src/mickey/data/*.json"]
  },
  "templates": ["src/mickey/templates/"]
}

The init command will generate the above manifest.json file for you if you don’t already have one. The generate property is an object containing different run configurations, or combinations of contexts and templates to render. The contexts property is where you define how to collect the different data contexts used to render the templates. The templates property is where you reference the location of the Jinja templates. Every template path, or remote package spec (defined later), will be moved into a .mickey_cache folder in the repository root. The templates can be referenced from there in generate or other templates in a similar manner to Python packages. Any local paths will be copied to .mickey_cache/<repository name>/path/to/templates, and can be referenced via <repository name>/<path>. For example, a set of templates at ./src/mickey/templates/examples, and listed in templates as above, will be copied to .mickey_cache/<repository name>/examples and can be referenced via <repository name>/examples.

In the example above, the examples definition means that every JSON file in ./src/mickey/data will be read and used to render all the templates. The run configuration example in generate then specifies to use the examples contexts, and for each file read render every template found in src/mickey/templates/examples/. The templates are rendered once for each context found, i.e. if there are 5 JSON files in ./src/mickey/data for the configuration above, the templates will be rendered 5 times.

Commands

• init: initialize a new Mickey repository, adds manifest.json if doesn’t exist.

• build: gather contexts and render templates per “generate” configs

• clean: remove all generated files