Two packages borrow the same ladder

A compiler that only understands one directory leads a sheltered life.

It knows every declaration personally. Nothing has to arrive from elsewhere. There are no neighbours with their own dependencies and an unfortunate habit of using familiar module names.

Let the neighbour stay local

A local dependency is a good first visitor.

[dependencies]
pooka_stdlib = { path = "../pooka_stdlib" }

Remember who asked

app/pooka.toml
  -> ../library/pooka.toml
       -> ../helper/pooka.toml

The second path is resolved from library, not from app.

The path belongs to the package that declares it. That sounds obvious until a transitive dependency resolves its own ../helper relative to the application’s directory and visits entirely the wrong building.

Package resolution needs to retain ownership: which package asked for this source, which modules it exposes, and which dependencies those modules are entitled to import. Seeing a package somewhere in the graph should not automatically make every one of its neighbours available to the root application.

Canonical paths matter too. Two spellings of the same directory should not disguise a dependency cycle. The resolver needs identities it can compare, rather than a collection of strings with optimistic punctuation.

Give the library somewhere to grow

pooka deps download
pooka check
pooka build

For local sources, resolution follows the configured directories; there is no archive to fetch from a registry.

For Pooka, getting this path working opens the next piece of the project. The standard library can live outside the compiler, and an application can depend on that library while both are still changing.

The source tree does not have to pretend to be a registry release before it can teach us anything.

Remote dependencies will need stronger promises: a Git revision to pin, or a registry version and checksum to verify. A lockfile is where those selected answers can be recorded for the next build.

Today the useful milestone is smaller. Code in one package can call code in another, with the compiler keeping track of whose names are whose.

The ladder reaches the next window. We can begin passing things across.

— Peregrine Finch

· pooka, packages, tooling