系统
lompi
Loment 的包管理器。它随工具链一起发布，且不是一个 loment
子命令 —— 一个独立的程序，有自己的版本和自己的指南。
一个库就是一个目录
没有清单格式要学，也没有第二种语言来写它。一个库就是一个装满 Loment 文件的目录， 而一个包系统通常会发明出来的三样东西，要么本就在语言里，要么从它推导出来，要么生成出来：
导出 —— 本就在语言里
pub。没有新东西要声明，没有东西要和源码保持同步。
依赖 —— use 行
有没有依赖列表。解析器读的是源码里已有的导入，所以"声明了却没用"和 "用了却没声明"根本不是它能产生的错误 —— 它们是不存在的状态。
身份 —— 一个递归内容哈希
一个包的身份，由它自己的源码加上它依赖的一切的身份一路向下算出来。只对一个 包自己的文件做哈希会是错的：同一份源码绑定到不同的依赖上就是不同的东西，那样会被 错误地合并。
正是最后这一条，消掉了一整类复杂度。没有版本区间语言，没有求解器，也没有解析冲突，因为 一个库的两个版本无非是两个身份 —— 而它们可以共存。
那个标签文件就是 Loment
一个包可以携带一个 .lomp 文件。它不是通常意义上的清单：它是 Loment
源码，至多有一个名字和一个版本要报告，而且它没有依赖小节 —— 因为依赖从一开始
就从不声明在文件里。不写它，目录名就是包名。
里面的版本号是给人看的标签。机器不用它们来选择任何东西；内容哈希已经把这件事做完了。
为什么不走通常的设计
库不能以二进制形式发布
泛型按每次实例化做单态化，所以编译器必须看到源码才能决定生成什么。一个编译好的二进制 块加头文件不是一个选项 —— 与之相伴的那类问题（让同一个接口的两份描述保持同步）也不是。
没有注册表服务
扩展点是磁盘上的文件。没有中心服务器来决定一个名字是什么意思。
它不是 loment 的一部分
lompi 与工具链一起安装，并且在你的 PATH 上，但它留在命令
面之外 —— loment help 不列出它，loment 也从不转发给它。
这道分离是有意为之，并被强制。
它今天接受什么。Loment 源码库。真正的 C 库可以通过
choose hosted 触达 —— 你在构建里点名那个库 —— 但它们还不是可安装的
依赖。安装外来的库，正是包管理器下一个版本要做的事。