lua - 什么是管理luockcks rockspec文件的好方法，为什么？

我正在开发我的第一个lua程序包，我对如何命名rockspec以及将它们放在何处感到非常困惑。我看过的每个流行的lua软件包似乎对岩石规范的处理方式都不相同。例如，这与Ruby完全不同，Ruby中的每个 gem 都只有一个gemspec。这里有些例子:

lua-cliargs:项目根目录中的单个rockspec(例如lua_cliargs-3.0-1.rockspec)

ldoc:项目根目录中的单个rockspec，以scm而不是版本号(例如ldoc-scm-2.rockspec)命名

lua-MessagePack:存储在顶级rockspec/目录(例如lua-messagepack-0.1.0-1.rockspec，... lua-messagepack-0.3.4-1.rockspec)中的多个版本名称的Rockspec，然后是一些在软件包版本之前插入了额外lua版本的版本(例如lua-messagepack-lua53-0.3.6-1.rockspec)。有时，对于同一软件包版本，有两种Rockspec，一种包含lua53，另一种不包含。

luafilesystem:存储在顶层/rockspec目录中的多个版本名称的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:根中的一个摇滚规范，其中包含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但缺少rockspec？

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

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

最佳答案

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



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

确实，这导致了鸡与蛋的问题，因为当人们从Github手动 check out 标记v1.0时，就没有最新的Foo 1.0 rockspec，但这不是预期的工作流程:使用LuaRocks时，用户通常会使用luarocks install foo;如果要 checkout 某个项目的岩石规范，则可以访问luarocks.org上Foo的页面，或者查看存储在HEAD中的岩石规范，这是人们首先停下来的地方。

请注意，如果要分发包含rockspec的源tarball，然后又要在rockspec中设置tarball source.url及其对应的source.md5，则会发生类似的“鸡与蛋”情况。在那儿拥有MD5意味着rockspec本身不能在tarball内。解决它的一种方法是简单地避开source.md5字段，或在打包tarball时跳过rockspec。这与在上游tarball中包含Linux分发程序包元数据的情况相同。这在这里更加明显，因为上游和包装商往往是同一个人。



可能是因为这是罕见的情况，上游和包装商不是同一个人。 Roberto Ierusalimschy发布了lpeg，但截至2016年12月，其摇滚规范由Gary Vaughan上传。



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

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

有些项目只是不经常更改其文件集，因此修订版仍然很低。

一些开发人员将其scm摇滚规范保留在-0(如“非已发布的修订版”中)，并且从不将其上传到luarocks.org(仅在其中保存已发布的版本)。因此，获取git修订版时得到的是该快照的有效版本。对于发行到luarocks.org的岩石规范，递增修订是一种预期的做法;

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

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

将最新的scm rockspec保留在根目录下具有一点好处，即如果要从本地 check out 的树中进行构建，则luarocks make会自动将其拾取。

但是，只要Rockspecs使用luarocks upload foo上传到服务器，最终用户的体验将是相同的，而不管Rockspecs在源代码树中的位置如何。

关于lua - 什么是管理luockcks rockspec文件的好方法，为什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40901215/