管理 luarocks rockspec 文件的好方法是什么，为什么？

Question

我正在开发我的第一个 lua 包，我对如何命名我的 rockspec(s) 以及将它们放在哪里感到非常困惑。我看到的每个流行的 lua 包似乎都以不同的方式处理 rockspecs。这与 Ruby 非常不同，Ruby 中的每个 gem 都只有一个 gemspec。以下是一些示例：

• lua-cliargs：项目根目录中的单个rockspec，（例如lua_cliargs-3.0-1.rockspec）
• ldoc：项目根目录中的单个 Rockspec，以 scm 命名而不是版本号（例如 ldoc-scm-2.rockspec）
• lua-MessagePack：多个以版本命名的rockspecs 存储在顶级rockspec/ 目录中（例如lua-messagepack-0.1.0-1.rockspec，...lua-messagepack-0.3.4-1.rockspec），然后是一些在包版本之前插入了额外的lua 版本（例如@ 987654335@)。有时，同一个包版本有两个 Rockspec，一个包含 lua53，一个不包含。
• luafilesystem：多个以版本命名的rockspecs存储在顶级/rockspec目录中（例如luafilesystem-1.3.0-1.rockspec，...luafilesystem-1.6.1-1.rockspec），后跟一些具有cvs而不是之前插入的包版本号软件包版本（例如luafilesystem-cvs-1.rockspec、luafilesystem-cvs-2.rockspec）。
• lpeg: 根本没有 Rockspec
• luasocket：根目录中的一个rockspec 包含scm 而不是包号（例如luasocket-scm-0.rockspec），和一个/rockspec 目录，其中包含一个带有包号的rockspec（例如@987654345 @)

现在，this question 解释了为什么会有一个“工作”的rockspec 文件和一个单独的目录，里面装满了发布版本的rockspec，但我还有几个问题：

1. rockspec 修订版有何用途？ luarocks wiki 说软件包发布应该在 git 中用版本号标记，它给出的示例不包括 rockspec 修订。如果我的 rockspec 在 VCS 中，并且我标记了一个特定的提交，那么这是否有效地修复了该提交中包含的 rockspec 以及版本？ Rockspec 的后续修订不可能在标记的提交中。
2. lpeg 怎么能在 luarocks 上列出但缺少 rockspec？
3. luarocks wiki 说如果您希望您的 Rockspec 引用 HEAD，则应使用 scm 代替软件包版本号。但由于HEAD 不断变化，并且rockspec 必须列出所有文件，因此似乎需要不断增加scm rockspec 的revision 编号以跟上任何添加或删除的文件.完全不使用scm rockspecs 的修订号可以解决这个问题，但我看到的修订号较低（例如ldoc-scm-2.rockspec）。这是一个错误吗？
4. 以上示例是否被视为最佳做法？

Answer 1

rockspec 修订版有什么用？

rockspec 修订版是 rockspec 文件本身的版本。假设您发布 Foo 1.0 版；你创建了一个rockspec foo-1.0-1.rockspec。后来你了解到要让 Foo 1.0 在 FreeBSD 中编译，你需要传递一个额外的 -D 标志；源代码根本不需要更改。您编辑 rockspec 添加一个platform override section 并将其重新提交给luarocks.org 作为foo-1.0-2.rockspec。

如果我的 rockspec 在 VCS 中，并且我标记了一个特定的提交，那么这不会有效地修复该提交中包含的 rockspec 和版本吗？

是的。但这不是问题，因为构建时使用的 rockspec 不是源代码分发中包含的。 .src.rock 文件是包含提交的 .rockspec 文件和源代码 tarball 的存档（如果 Rockspec 使用 SCM 协议，例如 git://，则在子目录中检出源代码）。

确实，这会导致一个先有鸡还是先有蛋的问题，因为当人们从 Github 手动签出标签 v1.0 时，Foo 1.0 的最新 Rockspec 不存在，但这不是预期的工作流程：使用 LuaRocks 时，用户通常会使用luarocks install foo；如果他们想查看项目的rockspecs，他们可以访问luarocks.org 的Foo 页面，或者他们会查看存储在HEAD 中的rockspecs，这是人们首先停留的地方。

请注意，如果想要分发包含 rockspec 的源 tarball，然后想要在 rockspec 中设置 tarball source.url 及其对应的 source.md5，则会发生类似的先有鸡还是先有蛋的情况。那里有 MD5 意味着 rockspec 本身不能在 tarball 中。一种解决方法是简单地避免使用source.md5 字段，或者在打包tarball 时跳过rockspec。这与将 Linux 分发包元数据包含在上游 tarball 中的情况相同；在这里更明显，因为上游和打包者往往是同一个人。

lpeg 怎么能在 luarocks 上列出却没有 rockspec？

可能是因为这是一种罕见的情况，上游和打包者不是同一个人。 Roberto Ierusalimschy 发布了 lpeg，但截至 2016 年 12 月，它的 rockspecs 由 Gary Vaughan 上传。

[...] 我看到的那些修订号较低（例如 ldoc-scm-2.rockspec）。这是一个错误吗？

这可能有很多原因，也可能是一个错误。

• 如果 Rockspec 使用 make 内置函数，那么在添加或删除文件时 scm rockspec 可能不会更改；
• 有些项目只是不经常更改他们的文件集，所以修订仍然很低；
• 一些开发人员将他们的scmrockspecs 保存在-0（如“未发布的修订版”中）并且从不将它们上传到luarocks.org（仅保留已发布的版本）。因此，当您获取 git 修订版时获得的版本是该快照的有效版本。增加修订是发布到luarocks.org 的 rockspecs 的预期做法；
• rockspec 确实可能已经过时，这是一个错误。

以上示例是否被视为最佳实践？

客观地说，由于运行luarocks install foo 时使用的rockspec 文件是捆绑在.src.rock 文件中的文件，与源档案分开存储，因此对于源代码树a 的确切位置没有重大的实际影响。开发人员存储他们的rockspecs。这是个人组织的问题。

在根目录中保留最新的scm rockspec 有一点优势，如果您想从本地签出树进行构建，luarocks make 会自动获取它。

但只要使用luarocks upload foo 将rockspecs 上传到服务器，最终用户体验将是相同的，无论rockspecs 在源代码树中的哪个位置。