luarocksのロックスペックファイルを管理する良い方法は何ですか？その理由は何ですか？

Question

私は最初のLUAパッケージに取り組んでいます。私は、ロックスペックの名前を付ける場所と配置する場所について深く混乱しています。私が見ているすべての人気のあるLUAパッケージは、ロックスペックを別々に扱うようです。これは、Rubyとはまったく異なります。Rubyでは、すべての宝石にただ一つのgemspecがあります。ここではいくつかの例は以下のとおりです。

• lua-cliargs：プロジェクトのルートに単一rockspec、（例えばlua_cliargs-3.0-1.rockspec）
• ldoc：scm代わりのバージョン番号（例：ldoc-scm-2.rockspec）と名付けられたプロジェクトのルートに単一rockspec、
• lua-MessagePack：トップレベルrockspec/ディレクトリに格納された複数のバージョン命名rockspecs（例えばlua-messagepack-0.1.0-1.rockspec、... lua-messagepack-0.3.4-1.rockspec）、パッケージ版の前に挿入された余分なLUAバージョンといくつかに続く（例えばlua-messagepack-lua53-0.3.6-1.rockspec）。時には、同じパッケージバージョンの2つのロックスペックがあります.1つはlua53を含み、もう1つはロックされていません。
• luafilesystem：トップレベル/rockspecディレクトリに格納された複数のバージョン命名rockspecs（例えばluafilesystem-1.3.0-1.rockspec、... luafilesystem-1.6.1-1.rockspec）、例えばluafilesystem-cvs-1.rockspec（代わりにパッケージのバージョンの前に挿入されたパッケージのバージョン番号のcvsを持っているいくつか続きます、 luafilesystem-cvs-2.rockspec）。
• lpeg：すべて
• luasocket何もありませんrockspec：代わりに、パッケージ番号（例えばluasocket-scm-0.rockspec）、とのscmを含むルートで1 rockspecパッケージ番号（例えばluasocket-3.0rc2-1.rockspec）を持つ単一のrockspecを含む/rockspecディレクトリ
今

、this questionは1が「作業」rockspecファイルとリリース・バージョン管理rockspecsの完全な別のディレクトリを持っているでしょう理由を説明し、私はまだいくつかの質問を持っている：

1. ロックスペックのリビジョンは何ですか？ luarocks wikiは、パッケージリリースにgitのバージョン番号を付けるべきだと言っています。この例では、Rockspecリビジョンは含まれていません。私のrockspecがVCS内にあり、特定のコミットにタグを付けると、そのコミットに含まれるrockspecを効果的に修正できないため、バージョンを修正することはできません。 rockspecの後のリビジョンは、おそらくタグ付けされたコミットにはありませんでした。
2. lpegはどのようにしてluarocksに登録できますか？rockspecが足りませんか？
3. ロックスペックがHEADを参照するようにするには、luarocks wikiによると、パッケージのバージョン番号の代わりにscmを使用する必要があります。しかし、HEADが絶え間なく変化しており、rockspecはすべてのファイルをリストしなければならないので、追加または削除されたファイルについていくためには、の番号を継続的にインクリメントする必要があります。これを回避するには、scm rockspecsのリビジョン番号を一切使用しないでください。しかし、私の見ているリビジョン番号は低い（例：ldoc-scm-2.rockspec）。これは間違いですか？
4. 上記の例のいずれかがベストプラクティスと考えられますか？

Answer 1

ロックスペックのリビジョンは何ですか？

rockspecリビジョンは、rockspecファイル自体のバージョンです。 Fooバージョン1.0をリリースしたとします。あなたはrockspec foo-1.0-1.rockspecを作成します。その後、FreeBSDでFoo 1.0をコンパイルするには、追加の-Dフラグを渡す必要があります。ソースコードはまったく変更する必要はありません。あなたはplatform override sectionを追加してrockspecを編集し、それをluarocks.orgにfoo-1.0-2.rockspecとして再提出します。

私のrockspecがVCS内にあり、特定のコミットにタグを付けると、そのコミットに含まれるrockspecが効果的に修正されないため、バージョンは有効になりませんか？

はい。しかし、これは問題ではありません。ビルド時に使用されたrockspecはソースディストリビューションに含まれていないためです。 .src.rockファイルは、提出された.rockspecファイルとソースコードtarball（またはのようなSCMプロトコルを使用する場合、サブディレクトリ内のソースチェックアウト）を含むアーカイブです。

確かに、Foo 1.0の最新のRockspecは、v1.0というタグをGithubから手作業でチェックするとそこにはないが、これは期待されるワークフローではない：LuaRocksを使うとき、ユーザーは通常luarocks install fooを使用します。プロジェクトのロックスペックをチェックアウトしたい場合は、luarocks.orgのFooのページにアクセスするか、HEADに格納されているロックスペックを参照します。これは、最初に停止する場所です。

rockspecを含むソースtarballを配布し、次にtarball source.urlとそれに対応するsource.md5をrockspecに設定したい場合、同様の鶏と卵の状況が発生することに注意してください。 MD5を持つことは、Rockspec自体がtarballの中にあることができないことを意味します。その周りの1つの方法は、単にsource.md5フィールドを避けるか、またはtarballをパッケージ化するときにrockspecをスキップすることです。これは、アップストリームのtarballにLinuxディストリビューションパッケージメタデータを含めるのと同じ状況です。それは上流と包装業者が同じ人物である傾向があるため、ここでより明白です。

lpegはどのようにluarocksに登録できますか？rockspecはありませんか？

おそらく、これはアップストリームとパッケージャが同じ人ではない場合がほとんどないためです。 Roberto Ierusalimschyはlpegをリリースしましたが、2016年12月現在、Gary Vaughanによってロックスペックがアップロードされています。

[...]私が見るものは、リビジョン番号が低い（例：ldoc-scm-2.rockspec）。これは間違いですか？

これには多くの理由があり、間違いの可能性があります。

• rockspecがmake組み込みを使用している場合は、ファイルが追加または削除された場合、その後、scm rockspecはそう変わりません。
• 一部のプロジェクトでは、しばしばそれらのファイルセットが変更されないため、リビジョンは低いままです。
• 一部の開発者は rockspecを-0（「リリースされていないリビジョン」のように）に保ち、決してluarocks.orgにアップロードすることはありません。ですから、gitリビジョンを取得したときに取得するものは、そのスナップショットの有効なものです。 rockspecsがluarocks.orgにリリースされた場合、リビジョンを増やすことが期待されています。
• rockspecが実際に古くなっている可能性があります。それは間違いです。

上記のいずれの例もベストプラクティスと考えられますか？客観1はluarocks install fooを実行するときに使用rockspecファイルは、ソースアーカイブとは別に保存され.src.rockファイル内にバンドル1であるため、場所を正確にソースツリー内の開発者として重大な実用的な影響がない、話す

そのロックスペックを保存します。それは個人的な組織の問題です。

最新のscm rockspecをルートに置くと、ローカルのチェックアウトされたツリーからビルドを作成する場合、luarocks makeによって自動的にピックアップされるというわずかな利点があります。

しかし、ロックスペックがluarocks upload fooでサーバーにアップロードされている限り、ソースツリー内のRockspecがどこにあるかにかかわらず、エンドユーザーエクスペリエンスは同じになります。