Depend on It

By the end of this page you'll have a separate project that pulls in palette and uses it — the payoff of publishing.

Step 1 — A new project

mkdir swatch
cd swatch
flock init

This one is an application rather than a library — it'll have an @main.

Step 2 — Add the dependency

A registry dependency is keyed by org/name. Add palette under [dependencies]:

[package]
name = "swatch"
version = "0.1.0"

[dependencies]
your-name/palette = { version = "0.1.0" }

On the next build, Flock fetches palette from the registry and writes a flock.lock that pins the exact resolved versions. Commit flock.lock for applications; libraries usually don't.

Developing two packages side by side? Point at the source instead with a path dependency — palette = { path = "../palette" } — same import, no publish needed.

Step 3 — Use it

Create src/main.ks:

module swatch

import palette.(Color)

@main
func main() -> lang.i32 {
    let brand = Color(red: 58, green: 123, blue: 213);
    println(brand.toHex());

    match Color(hex: "#0a0005") {
        .Some(c) => println("parsed \(c.red)"),
        .None    => println("not a color")
    }
    0
}

You import by the package's module name (palette), not its org: import palette.(Color) brings the public Color type into scope. Only public items are importable — which is exactly why the internal channel helper from page 1 stays invisible here.

Step 4 — Run it

flock run

#3a7bd5
parsed 10

That's palette doing the work from inside another package.

What you actually depended on

Only the public API is reachable — Color, its initializers, and toHex. Internal helpers never leak into a dependent.
The build is reproducible. The version constraint ("0.1.0") plus flock.lock mean everyone who builds swatch resolves the same palette.

Next: Ship a New Version — change palette, release 0.2.0, and see how semantic versioning flows to dependents.