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)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| 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.