Nutri-Matic

Author: Jared Cook
Version: 0.1.14

Overview

Cookiecutter utilities for streamlining development and utilization of Cookiecutter templates.

---

---

📦 Package Information:

GitHub: Source Code
GitDocs: Api Documentation

📦 Package Installation:

PyPi: (stable)

$ python -m pip install nutri-matic

TestPyPi: (development)

$ python -m pip install -i https://test.pypi.org/simple/ nutri-matic

Command Examples:

🔧 nutrimatic (add_docs, extract, run, list)

Add Docs:

Description: Add GitHub docs to an existing project using the github-docs-cookiecutter template.

$ nutrimatic add-docs $(target_dir)

Extract:

Description: Clone a repo, extract cookiecutter.json, remove Jinja placeholders, save locally.

Run extract command to local cookiecutter repository:

$ nutrimatic extract ./python3-cookiecutter

OR: Run extract command to from github cookiecutter repository:

$ nutrimatic extract \
    --repo git@github.com:jcook3701/python3-cookiecutter.git \
    --branch develop \
    --output clean_cookiecutter.json

AFTER: Modify extracted json to meet you new projects requirements.

Run:

Description: Run a cookiecutter template using a pre-supplied JSON configuration file.

$ nutrimatic run $(template) $(config)

List:

Description: List available cookiecutter templates under a namespace.

$ nutrimatic list

---

⚙️ Config (nm-config)

Description: nutrimatic configuration tools.
Note: These are tools that are used to manage package configuration file.
Sub-commands: (show)

Show:

Description:

$ nm-config show

---

🔨 Build (nm-build)

Description: Cookiecutter build automation utilities.
Note: These commands are intended to be used within project Makefiles as build tools. Examples will assume for use in Makefile.
Sub-commands: (readme, add-yaml-front-matter)

Readme:

Description: Generates project readme from projects github-docs jekyll project. The intention is keep the readme within ./docs/jekyll as the project’s single source of truth.
Note: Intended for use within project Makefile as shown below.

PROJECT_ROOT := $(PWD)
DOCS_DIR := $(PROJECT_ROOT)/docs
JEKYLL_DIR := $(DOCS_DIR)/jekyll
JEKYLL_BUILD := bundle exec jekyll build --quiet
README_GEN_DIR := $(JEKYLL_DIR)/tmp_readme
README_FILE := $(PROJECT_ROOT)/README.md
readme:
nm-build readme $(JEKYLL_DIR) $(README_FILE) </span>
--tmp-dir $(README_GEN_DIR) --jekyll-cmd '$(JEKYLL_BUILD)'

add-yaml-front-matter:

Description: This adds yaml-front-matter to the head of (md, yml, & yaml) files to help beautify github docs. Intended to be used with github-docs-cookiecutter

$ nm-build add-yaml-front-matter < Directory > --project < Project Name >  

---

🍪 Template (nm-templates)

Description: nm-templates tools.
Note: github-docs-cookiecutter will either be moved to cc-templates or be added to cc-templates as a submodule.
Sub-commands: (generate)

Generate:

Description: This is for custom Cookiecutter template (cc-templates) that utilizes ccmeta.toml files to organize projects.
Note: This feature is still in development. (Use at your own risk!!!)
Arguments:

• repo: Path to the template repository to generate README.md and Makefile

$ nm-templates generate $(repo)

---

Development Strategy:

🐍️ Build environment (.venv)

Description: This creates python virtual environment and installs all necessary packages.

$ make install

CI/CD Checklist: 🧬 + 🛡️ + 🎨 + 🔍 + 🎓 + 🧠 + 🧪

Description: Runs all checks that are used for CI/CD. This should pass without error before attempting a pull-request.
Note: All Makefile commands are used in CI/CD to ensure that if they pass locally they should also pass once pushed to github.

$ make pre-commit

🧪 📢 Test Release Project (Test PyPi):

Description: This runs the entire build cycle and results in a new test release to test.pypi.

$ make test-release

📢 Release Project (Github & PyPi):

Description: This runs the entire build cycle and results in a new release to Github and Pypi. Project is also versioned up after release has been published.

$ make release

---

Make Toolkit (Individual Commands):

🧬 Dependency Management (deptry)

$ make dependency-check

🛡️ Security Audit (pip-audit)

$ make security

🎨 Formatting (black)

$ make format-check

$ make format-fix

🔍 Linting (ruff, toml, & yaml-lint)

$ make lint-check

$ make lint-fix

🎓 Spellchecking (codespell)

$ make spellcheck

🧠 Typechecking (mypy)

$ make typecheck

🧪 Testing (pytest)

$ make test

📦 Building (build)

$ make build

🚀 Publishing (Twine + Github)

$ make publish

🔖 Version Bumping (bumpy-my-version)

$ make bump-version-patch

❓ Build Help

$ make help

---

Commit Help:

Note: Commits are required to be conventional git commit message. This helps with the auto-generation of the changelog files and is enforced by pre-commit.
example:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

• <type>: A required noun that describes the nature of the change.
• [optional scope]: An optional phrase within parentheses that specifies the part of the codebase being affected (e.g., fix(parser):).
• <description>: A required short, imperative-mood summary of the changes.
• [optional body]: A longer description providing additional context and “what and why” details.
• [optional footer(s)]: Used for adding meta-information, such as issue references (Fixes #123) or indicating breaking changes.

---

Requirements:

Python 3.11

$ sudo apt install python3.11

rustup

Note: I found that it is easiest to use rustup to manage rustc and cargo but this is not required.
Example: Install rustup with the following:

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

git-cliff

Note: git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers.

$ cargo install git-cliff

---

🍹Authors Notes:

Their fundamental design flaws are completely hidden by their superficial design flaws.

TODO’s:

1. cc-templates/ccindex.toml
   • create/update this file using the individual ccmeta.toml files in cc-templates
2. Finish updating this.readme with command usage.
3. Readme make readme should end up being a ci/cd process to ensure it is always up to date.
4. Thinking about adding a ci/cd process for version bumping. To create a git tag.

Future Design Decisions:

1. I need to decide whether to change all my current Cookiecutter projects to use the prefix cc- and use them as submodules within the cc-templates repository. Or to just move the code directly into the cc-templates repository and use it as a monolithic repo.