1. Installation

cook is a single Rust binary with a bundled Lua runtime and a bundled LuaRocks. No package manager to fight, no system Lua to match, no separate server.

Linux and macOS:

curl -fsSL https://getcook.sh | sh

This installs a self-contained tree under ~/.cook/ (the cook binary plus a bundled Lua 5.4 and LuaRocks) and puts cook on your PATH via ~/.cook/bin. Point it elsewhere with COOK_INSTALL_DIR=/opt/cook. To update, re-run the same command; the script is idempotent and only replaces the tree if you’re behind.

From source:

cd cli
cargo install --locked --path crates/cook-cli

Running the command from cli/ lets Cargo load cli/.cargo/config.toml, which exports the embedded Lua symbols required by native Lua rocks.

Source-build linking

cook statically embeds its own Lua 5.4; no system Lua is consulted. A native (C) rock resolves the Lua C API from the cook executable when it loads, so a source-built binary must export those symbols. Builds run from cli/ pick up the correct linker flag from cli/.cargo/config.toml automatically.

Cargo reads configuration from the directory where you invoke it, not from a package fetched by cargo install. When installing directly from Git, pass the flag explicitly:

# Linux
RUSTFLAGS="-C link-arg=-rdynamic" \
    cargo install --locked --git https://github.com/LioraLabs/cook cook-cli

# macOS
RUSTFLAGS="-C link-arg=-Wl,-export_dynamic" \
    cargo install --locked --git https://github.com/LioraLabs/cook cook-cli

Without the flag, pure-Lua modules still work. The failure appears only when a native rock loads: dlopen succeeds, then lua_* symbol lookup fails with an error that does not look like a linker problem.

Verify:

cook --version

Per-project state lives in a .cook/ directory (the content-addressed cache and build logs). It’s safe to delete (the next build repopulates it), and cook init writes a .gitignore that keeps it out of version control. To remove cook entirely: rm -rf ~/.cook.