Skip to main content

hmd-cli-mickey

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

Metadata

Release files for hmd-cli-mickey 1.0.51

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for hmd-cli-mickey 1.0.51
File Interpreter ABI Platform
hmd_cli_mickey-1.0.51-py3-none-any.whl Python 3 none any Details

Release files / hmd_cli_mickey-1.0.51-py3-none-any.whl

Download URL hmd_cli_mickey-1.0.51-py3-none-any.whl
Size 8.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
6f5fff266fc2e9f86f5f4921d8c83d835896a028943313d7eab2a4639a554bc8
BLAKE2b-256 checksum
How to use checksums
ee6d813e10b3f661b430ff10644b782138eea5f1562186f51b4cac4e1d04dc6d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.2 CPython/3.9.5

Security for hmd-cli-mickey 1.0.51

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page