Ewok (Education Warehouse Octopus Kit) is a powerful CLI framework built on top of Invoke and Fabric. It extends them with features for plugin-based, composable command-line tools.
Follow these steps to create a basic Ewok-powered CLI.
my_project/
├── src/
│ └── my_package/
│ ├── __init__.py
│ └── tasks.py
├── pyproject.toml
You can merge your CLI into __init__.py for simplicity.
# src/my_package/__init__.py
from ewok import App
from . import tasks
app = App(
name="myapp",
version="0.1.0",
core_module=tasks,
)# src/my_package/tasks.py
from ewok import task, Context
# you can also import Context from invoke instead; ewok.Context is an alias
@task
def hello(c: Context, name: str = "world"):
"""Print a friendly greeting"""
print(f"Hello, {name}!")[project]
name = "my-project"
version = "0.1.0"
dependencies = [
"ewok>=0.1.0",
# other dependencies...
]
[project.scripts]
myapp = "my_package:app"
myappwill be installed as an executable that runs theappobject.
# The `-e` flag performs an editable install — useful while developing.
uv pip install -e .Then try your CLI:
myapp hello --name AliceHello, Alice!
-
Multi-source Task Integration:
- Core tasks from your package
- Plugin tasks via entry points (namespaced)
- Personal tasks from
~/.config/<name>/tasks.py - Project-local
tasks.py(namespaced aslocal.) - Extra namespaced modules like
dev.tasks.py→dev.taskname
-
Plugin System: Discover and load tasks from external packages
-
Flexible Namespacing: Mix-and-match functionality per project, plugin, and personal
-
Invoke/Fabric Compatible: Supports all base task features
Ewok’s App class wraps and extends Invoke’s CLI system.
These options extend the default behavior of Invoke/Fabric:
| Parameter | Description | Default |
|---|---|---|
name |
Name of your CLI tool (used in help/version) | Required |
version |
App version string | Required |
core_module |
Your main task module | Required |
extra_modules |
Tuple of additional task modules (each auto-namespaced) | () |
plugin_entrypoint |
Entry point group(s) for plugin discovery | name |
config_dir |
Where to look for personal tasks (e.g. ~/.config/<name>) |
~/.config/{name} |
include_project |
Load project-specific *.tasks.py modules |
True |
include_local |
Load tasks.py from the current directory (under local. namespace) |
True |
ewok_modules |
Include Ewok's own internal modules (not in use yet) | True |
In addition to the standard @task() parameters from Invoke/Fabric, Ewok supports two additional parameters:
Type: dict[str, list[str]]
The flags parameter allows you to define additional CLI flags that map to boolean function parameters:
@task(flags={'exclude': ['--exclude', '-x'], 'as_json': ['--json']})
def deploy(c: Context, exclude: bool = False, as_json: bool = False):
"""Deploy with optional exclusions and JSON output"""
if exclude:
print("Excluding test files...")
c.run("echo 'some shell command'")
if as_json:
return {"status": "deployed"}
print("Deployment complete!")This enables calling your task with the defined flags:
myapp deploy --exclude --json
# or using the short form:
myapp deploy -x --jsonType: Optional[bool]
Controls whether the task can participate in "hook" chaining behavior:
True→ This is a core task that can trigger other tasks with the same name (e.g., from plugins or local modules) after it runs.False→ This task should not be hooked, even if another with the same name exists. Typically used in plugins or local overrides.None(default) → Default behavior: core tasks don't hook; plugin/local tasks can be hooked.
Here's a concrete example showing how the hook system works with a setup task:
Core module (tasks.py):
@task(hookable=True)
def setup(c: Context):
"""Core setup - runs first, triggers other setup tasks"""
print("🔧 Core setup: Creating docker-compose.yml and .env files...")
# Create essential config files that every project needs
create_docker_compose()
create_env_template()Local tasks (tasks.py in project directory):
@task # hookable=None (default) - will be called after core
def setup(c: Context):
"""Project-specific setup questions"""
print("🏠 Local setup: Configuring project settings...")
check_env(
key="DOMAIN",
default="localhost",
comment="The hosting domain for this project"
)
set_file_permissions()Plugin (backup plugin):
@task # hookable=None (default) - will be called after core
def setup(c: Context):
"""Backup plugin setup"""
print("💾 Backup setup: Configuring backup storage...")
check_env(
key="BACKUP_PATH",
default=get_default_backup_path(),
comment="Where backups should be stored"
)Plugin with non-hookable task (e.g. nuke.tasks.py):
@task(hookable=False) # This will NOT run automatically
def setup(c: Context):
"""Destructive setup - only run when explicitly called"""
print("💣 Nuclear setup: This will destroy existing config!")
# Only runs when called as: myapp nuke.setupExecution flow for this example when you run myapp setup:
- Core setup runs first (creates base files)
- Plugin setup runs next (configures backup storage)
- Local setup runs last (asks project-specific questions)
setupwithhookable=Falsedoes NOT run (because it's explicitly excluded from the hook chain)
This allows you to build layered functionality where each level can extend the setup process, but dangerous or unrelated operations require explicit invocation.
Ewok supports plugin discovery via Python entry points, allowing you to extend your CLI with external packages.
- Create a plugin package with its own
tasks.py:
# my_plugin/tasks.py
from ewok import task
@task
def greet(c):
"""Plugin greeting task"""
print("Hello from the demo plugin!")
@task
def status(c):
"""Show plugin status"""
print("Demo plugin is active")- Register the plugin in the plugin's
pyproject.toml:
[project.entry-points.myapp] # Must match your main app's name
demo = "my_plugin.tasks" # 'demo' becomes the namespace prefixThe entry point name (demo in this example) determines the namespace. Tasks from this plugin will be accessible as demo.greet, demo.status, etc.
- Install and use the plugin:
# Install the plugin package
uv pip install my-plugin-package
# Use the plugin tasks
myapp demo.greet # Calls the greet task from the demo namespace
myapp demo.status # Calls the status task from the demo namespaceYou can configure your app to discover plugins from multiple entry point groups:
app = App(
name="myapp",
version="1.0.0",
core_module=tasks,
plugin_entrypoint=("myapp", "myapp_plugins"), # Search both groups
)This allows plugin authors to register under either myapp or myapp_plugins entry points.
Task sources and their namespaces:
| Source | Example Call | Namespace |
|---|---|---|
| Core task module | myapp hello |
global |
| Plugin via entry point | myapp demo.taskname |
demo. |
Project-local tasks.py |
myapp local.taskname |
local. |
Namespaced dev.tasks.py |
myapp dev.taskname |
dev. |
Personal ~/.config/myapp/ |
myapp taskname |
global |
Control which task sources are loaded at runtime:
| Flag | Description |
|---|---|
--no-local |
Skip tasks.py in the current directory |
--no-project |
Skip namespaced *.tasks.py in the project |
--no-personal |
Skip ~/.config/<name>/tasks.py |
--no-plugins |
Skip plugin discovery entirely |
--no-packaged |
Skip installed plugin packages |
--no-ewok |
Skip Ewok’s own built-in modules |
# src/my_package/__init__.py
from pathlib import Path
from ewok import App
from . import tasks, extra, slow
from .__about__ import __version__
app = App(
name="my-app",
version=__version__,
core_module=tasks, # not namespaced
extra_modules=(extra, slow), # namespaced as `extra.` and `slow.`
plugin_entrypoint=("my-app", "myapp_plugins"),
# only if it differs from 'name', can also be multiple or None to disable
config_dir=Path("~/custom-config/my-app"), # only if it differs from 'name', can also be a Path or None to disable
include_project=True, # to include project-specific tasks.py and <namespace>.tasks.py files
include_local=True, # to include tasks.py in the local cwd and up your file tree (../tasks.py etc.)
)- 🧪 Minimal template: ewok-example
- 🧰 Real-world usage: edwh
