Common Lisp 风格：同一个 repo 中的多个包
Common Lisp style: multiple packages in same repo
我可以为多个相关的 Common Lisp 包获得具有良好风格的代表性代码存储库的推荐或链接吗？
例如，考虑一个高级工作流库和伴随的低级 API，每个库都在自己的 CL 包中，但由于同步发布，所以相同的 git 回购。
每个系统（*.asd 文件）隔离测试并可以使用以下方式调用：
(asdf:test-system foo :force t)
可以通过 make 构建单独的系统，这绝对有助于隔离 SBCL 代码覆盖率报告。
库的某些用户可能只想加载较低级别的 API。为了简化那些使用更高级别 API 的人的依赖关系，似乎最好将所有内容捆绑在一个回购协议中。对一个库的任何修订都可能需要为同一版本更新所有库。
我目前有一个目录树，每个 CL 包都有一个子目录。库维护将使用的每个子目录中都有一个顶级 Makefile 加一个。顶层还包含指向相关子目录的 .asd 文件的符号链接。 （这是一个严重依赖于通过 uiop-posix 调用 POSIX 的库，因此它仅适用于具有符号链接的 OS。）
考虑到 Quicklisp-docs [0] 的问题 #1，这似乎是一个普遍的问题。
在 Google 的 CL 风格指南 [1]、State of the Common Lisp Ecosystem，2015 [2]、Edi 的 CL Recipes [3] 或 Lisp-lang [4] 中找不到任何相关内容。浏览 repos 似乎有相当多的风格。
- [0] https://github.com/rudolfochrist/quicklisp-docs/issues/1
- [1] https://google.github.io/styleguide/lispguide.xml
- [2]https://web.archive.org/web/20160305061250/http://eudoxia.me/article/common-lisp-sotu-2015/
- [3]http://weitz.de/cl-recipes/
- [4] http://lisp-lang.org/learn/writing-libraries 但另请参阅他们关于持续集成的部分
要修复的回购：https://gitlab.com/dpezely/cl-mmap
（提交 2018-07-14 的 a23bd88d；修复后将标记发布）
您可以考虑使用 asdf-inferred-package。这样，您就可以拥有一个依赖于 mmap/low 包的 mmap/high 包。使用该设置，您实际上可以让 Quicklisp 直接加载它们中的任何一个：
(ql:quickload "mmap/high")
或
(ql:quickload "mmap/low")
您可以在我的 cl-bulk 存储库中查看示例。
试图接触到可能没有在这里看到问题的特定受众，posted 到 Common Lisp Pro 邮件列表。
各种回应的总结——除了对未来各种可能方向的深刻见解——没有事实上惯例、机制或风格来解决各种因素的组合:
- 相互关联的依赖同步libraries/packages/systems
- 容纳每个单独加载
- 单独进行测试
- 容纳每个人的代码覆盖率报告
在添加此答案时，最接近一致的、具体的、现有的解决方案似乎与原始 post 中提到的包已经实现的内容一致——或者足够接近。 （当然，这里的早期答案表明存在细微的设计和命名差异，但我认为这些变化具有可比性。）
作为示例建议的软件包和系统的要点：
- CLIM 的早期实现（早于 McCLIM），用于将 API 与实现
分开
- 尽管在 ASDF 中常规使用 ASDF systems and packages, explore how UIOP 本身是结构化的
- ASDF 和 LIL 进口和再出口
目录中的所有符号；见 Faré's full summary
未来的方向和建议的阅读包括：
- 将该交集视为软件工程问题，并据此构建，因为"In short: it depends!"
- 球拍模块或Gerbil Scheme
- 也许 Google's CL style guide 的内部更新添加了相关内容？
（非常感谢 Pascal J. Bourguignon、Ken Tilton、Scott McKay、Faré、Svante v. Erichsen、Don Morrison 和 Pascal Costanza 参与电子邮件讨论。）
我可以为多个相关的 Common Lisp 包获得具有良好风格的代表性代码存储库的推荐或链接吗？
例如，考虑一个高级工作流库和伴随的低级 API，每个库都在自己的 CL 包中，但由于同步发布，所以相同的 git 回购。
每个系统（*.asd 文件）隔离测试并可以使用以下方式调用：
(asdf:test-system foo :force t)
可以通过 make 构建单独的系统，这绝对有助于隔离 SBCL 代码覆盖率报告。
库的某些用户可能只想加载较低级别的 API。为了简化那些使用更高级别 API 的人的依赖关系，似乎最好将所有内容捆绑在一个回购协议中。对一个库的任何修订都可能需要为同一版本更新所有库。
我目前有一个目录树，每个 CL 包都有一个子目录。库维护将使用的每个子目录中都有一个顶级 Makefile 加一个。顶层还包含指向相关子目录的 .asd 文件的符号链接。 （这是一个严重依赖于通过 uiop-posix 调用 POSIX 的库，因此它仅适用于具有符号链接的 OS。）
考虑到 Quicklisp-docs [0] 的问题 #1，这似乎是一个普遍的问题。
在 Google 的 CL 风格指南 [1]、State of the Common Lisp Ecosystem，2015 [2]、Edi 的 CL Recipes [3] 或 Lisp-lang [4] 中找不到任何相关内容。浏览 repos 似乎有相当多的风格。
- [0] https://github.com/rudolfochrist/quicklisp-docs/issues/1
- [1] https://google.github.io/styleguide/lispguide.xml
- [2]https://web.archive.org/web/20160305061250/http://eudoxia.me/article/common-lisp-sotu-2015/
- [3]http://weitz.de/cl-recipes/
- [4] http://lisp-lang.org/learn/writing-libraries 但另请参阅他们关于持续集成的部分
要修复的回购：https://gitlab.com/dpezely/cl-mmap
（提交 2018-07-14 的 a23bd88d；修复后将标记发布）
您可以考虑使用 asdf-inferred-package。这样，您就可以拥有一个依赖于 mmap/low 包的 mmap/high 包。使用该设置，您实际上可以让 Quicklisp 直接加载它们中的任何一个：
(ql:quickload "mmap/high")
或
(ql:quickload "mmap/low")
您可以在我的 cl-bulk 存储库中查看示例。
试图接触到可能没有在这里看到问题的特定受众，posted 到 Common Lisp Pro 邮件列表。
各种回应的总结——除了对未来各种可能方向的深刻见解——没有事实上惯例、机制或风格来解决各种因素的组合:
- 相互关联的依赖同步libraries/packages/systems
- 容纳每个单独加载
- 单独进行测试
- 容纳每个人的代码覆盖率报告
在添加此答案时，最接近一致的、具体的、现有的解决方案似乎与原始 post 中提到的包已经实现的内容一致——或者足够接近。 （当然，这里的早期答案表明存在细微的设计和命名差异，但我认为这些变化具有可比性。）
作为示例建议的软件包和系统的要点：
- CLIM 的早期实现（早于 McCLIM），用于将 API 与实现 分开
- 尽管在 ASDF 中常规使用 ASDF systems and packages, explore how UIOP 本身是结构化的
- ASDF 和 LIL 进口和再出口 目录中的所有符号；见 Faré's full summary
未来的方向和建议的阅读包括：
- 将该交集视为软件工程问题，并据此构建，因为"In short: it depends!"
- 球拍模块或Gerbil Scheme
- 也许 Google's CL style guide 的内部更新添加了相关内容？
（非常感谢 Pascal J. Bourguignon、Ken Tilton、Scott McKay、Faré、Svante v. Erichsen、Don Morrison 和 Pascal Costanza 参与电子邮件讨论。）