Packages

Teko is packaged as mc packages, in mc's own registry — there is one integrated index, not a teko one beside an mc one. This page separates what a build reads today from what is agreed and not yet live; the full agreement is ../specs/packages.md.

Today: two files at the root #

filerole
teko.tomlthe build config — mc build . --config teko.toml
mc.tomlthe package manifest: [package] only, read by mc pkg

They cannot be one file: mc pkg hash DIR reads DIR/mc.toml and takes no --config. The manifest carries no [project], and that absence is what makes the name a library rather than a tool; it also carries language = "teko" and licence, both written now so that the first publication does not have to change the manifest again. language is an override — a package that instead declares [deps] teko (a library, never the compiler itself) is classified teko from that dependency alone, with no key of its own to write.

[package]
name     = "teko"
language = "teko"
licence  = "MIT OR Apache-2.0"
lib      = "lib/rt.tk"
files    = [ "core_teko.mc", "lib/rt.tk", "teko.tk", "..." ]
check    = ["mc_teko.tk"]

files is the exact list a consumer would receive and the bytes the tree hash digests; check names the units the registry compiles on their own to prove the package builds.

Today: consuming teko from a checkout #

Until the package is published, a consumer names the modules of a teko checkout by path in its own build config, and gets the taught compiler out of its own mc build:

[compiler]
core    = "<mc/core_min>"
modules = ["core_teko.mc", "teko.tk", "user.mc"]
out     = "build/teko"

That is exactly what teko.toml does for this repository, and it is the road that keeps working after publication.

Planned: pinning the package #

Once teko is published, the same build config names the package instead of the paths, and the version pins the bytes through the lock:

[deps]
teko     = "0.4.0"
teko_std = "0.4.0"

[compiler]
core    = "<mc/core_min>"
modules = ["<teko/core_teko.mc>", "<teko/teko.tk>", "user.mc"]
out     = "build/teko"

The library is then included by package name, with the extension spelled out — mc drops a trailing .mc from an angle-bracket name and does not drop .tk:

// no-run
#include <teko_std/strings.tk>

teko_std does not exist yet. What a program includes today is the runtime, #include "rt.tk", from this repository (runtime.md).

Planned: three shapes, and how a package is validated #

packagewhat it isversion line
tekothe compiler: the hook modules a consumer names in [compiler].modulesits own
teko_stdthe standard librarylockstep with teko — same tag, released together
any other librarya teko library published by anyoneits own, over [deps] teko_std

For a package classified teko — by [package].language or by a [deps] teko of its own — the registry will build the taught compiler from [package].modules and the package's [deps] first, in a sandbox with no network, and compile the check units with it — which is what lets a teko library declare check units written in teko. Until that support lands, the validator compiles check with the stock mc, which is why this repository's own check unit, mc_teko.tk, is written in core syntax.

The closure rule is mc's: a package reaches its own files, the libraries the binary ships and its declared [deps], and nothing else. Compiler modules run at build time inside the compiler mc build assembles, so a teko dependency is trusted code and the lock is the review.

tekoc, the compiler as an executable package, is a separate name published later: a package's kind is fixed at its first publication, so a library and a tool cannot share one.

Edit this page