lua - 什么是管理 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 版本的目录(例如 lua-messagepack-lua53-0.3.6-1.rockspec )。有时同一个包版本有两个rockspecs，一个包含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 的目录(例如 luasocket-3.0rc2-1.rockspec )

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

什么是 rockspec 修订版？ luarocks wiki 说软件包发布应该在 git 中用版本号标记，它给出的示例不包括 rockspec 修订。如果我的 rockspec 在 VCS 中，并且我标记了一个特定的提交，那么这是否有效地修复了该提交中包含的 rockspec 以及版本？ Rockspec 的后续修订不可能在标记的提交中。

怎么可能lpeg被列入 luarocks 但缺少 rockspec ?

luarocks wiki 说 scm如果您希望您的 rockspec 引用 HEAD，则应使用该软件包版本号代替。但是自从HEAD不断变化，并且rockspec必须列出所有文件，似乎需要不断增加revision scm 的数量rockspec 以跟上任何添加或删除的文件。可以通过完全不使用 scm 的修订号来解决此问题。 rockspecs，但我看到的那些修订号较低(例如 ldoc-scm-2.rockspec )。这是一个错误吗？

上述任何示例是否被视为最佳实践？

Answer 1

What are rockspec revisions for?

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 .

If my rockspec is in VCS, and I tag a particular commit, then doesn't that effectively fix the rockspec(s) included in that commit and therefore version?

是的。但这不是问题，因为构建时使用的 rockspec 不是源代码分发中包含的。一个 .src.rock文件是包含提交的文件.rockspec文件和源代码 tarball(如果 rockspec 使用 SCM 协议(protocol)，例如 git://，则在子目录中 check out 源代码)。

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

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

How can lpeg be listed on luarocks but lack a rockspec?

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

[...] the ones I see have low revision numbers (e.g. ldoc-scm-2.rockspec). Is this a mistake?

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

如果 Rockspec 使用 make内置，然后是 scm添加或删除文件时，rockspec 可能不会更改；

有些项目只是不经常更改他们的文件集，所以修订仍然很低；

一些开发人员保留他们的scm岩石规范在 -0 (如“不是已发布的修订版”)并且永远不要将它们上传到 luarocks.org (仅保留已发布的版本)。因此，当您获取 git 修订版时获得的版本是该快照的有效版本。增加修订是发布到 luarocks.org 的 rockspecs 的预期做法。 ;

rockspec 可能确实已经过时了，这是一个错误。

Are any of the above examples considered a best practice?

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

保持最新scm根目录中的rockspec 有一点优势，它会被luarocks make 自动拾取。如果有人想从本地 checkout 树构建。

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