System
lompi
Loment's package manager. It ships with the toolchain and it is
not a loment subcommand — a separate program, with its
own version and its own guide.
A library is a directory
There is no manifest format to learn and no second language to write it in. A library is a directory full of Loment files, and the three things a package system normally invents are either already in the language, derived from it, or generated:
Exports — already in the language
pub. Nothing new to declare, nothing to keep in sync with the source.
Dependencies — the use lines
There is no dependency list. The resolver reads the imports the source already has, so "declared but not used" and "used but not declared" are not errors it can even produce — they are not states that exist.
Identity — a recursive content hash
A package's identity is computed from its own source and the identities of everything it depends on, all the way down. Hashing a package's own files alone would be wrong: the same source bound to different dependencies is a different thing, and would be merged by mistake.
That last one is what removes an entire category of complexity. There is no version range language, no solver, and no resolution conflict, because two versions of a library are simply two identities — and they can coexist.
The label file is Loment
A package may carry a .lomp file. It is not a manifest in the usual sense:
it is Loment source, with at most a name and a version to report, and
it has no dependency section — because dependencies were never declared in a file to
begin with. Left out, the directory name is the package name.
The version numbers in it are labels for people. The machine does not use them to choose anything; the content hash already did that.
Why not the usual design
Libraries cannot ship as binaries
Generics are monomorphised per instantiation, so the compiler has to see the source to decide what to generate. A compiled blob plus headers is not an option — and neither is the class of problems that comes with keeping two descriptions of one interface in step.
No registry service
The extension points are files on disk. There is no central server deciding what a name means.
It is not part of loment
lompi installs alongside the toolchain and is on your PATH,
but it stays out of the command surface — loment help does not list it,
and loment never forwards to it. That separation is deliberate and
enforced.
What it takes today. Loment source libraries. Real C libraries are
reachable through choose hosted — you name the library in the build — but
they are not yet an installable dependency. Installing foreign libraries is
what the next release of the package manager is for.