Что такое хороший способ управления файлами luarocks rockpec и почему?

Question

Я работаю над своим первым пакетом lua, и я глубоко озадачен тем, как назвать мои скалистые спекуты и где их разместить. Кажется, что каждый популярный пакет lua, с которым я обращаюсь, по-разному относится к горным спецификациям. Это сильно отличается от, скажем, Ruby, где каждый драгоценный камень имеет только один gemspec, Вот некоторые примеры:

• lua-cliargs: единая скала в корне проекта (например, lua_cliargs-3.0-1.rockspec)
• ldoc: одна скала в корне проекта, названная scm вместо номера версии (например, ldoc-scm-2.rockspec)
• lua-MessagePack: несколько скалистых версий с именами версий, хранящихся на верхнем уровне rockspec/ каталог (например, lua-messagepack-0.1.0-1.rockspec... lua-messagepack-0.3.4-1.rockspec), а затем некоторые с дополнительной версией lua, вставленной перед версией пакета (например, lua-messagepack-lua53-0.3.6-1.rockspec). Иногда для одной и той же версии пакета существуют две спецификации спекуляции, одна из которых содержит lua53, а другая - нет.
• luafilesystem: несколько версий с именами версий, хранящихся на верхнем уровне /rockspec каталог (например, luafilesystem-1.3.0-1.rockspec... luafilesystem-1.6.1-1.rockspec), а затем некоторые, которые имеют cvs вместо номера версии пакета, вставленного перед версией пакета (например, luafilesystem-cvs-1.rockspec, luafilesystem-cvs-2.rockspec).
• lpeg: нет горной породы вообще
• луасокет: один камень в корне, содержащий scm вместо номера пакета (например, luasocket-scm-0.rockspec) и /rockspec каталог, содержащий одну скалу с номером пакета (например, luasocket-3.0rc2-1.rockspec)

Теперь этот вопрос объясняет, почему нужно иметь "работающий" файл rockpec и отдельный каталог, полный версий-релизов с версионной версией, но у меня все еще есть несколько вопросов:

1. Для чего нужны версии Rockpec? Вики luarocks говорит, что выпуски пакетов должны быть помечены в git номером версии, и приведенный пример не включает в себя ревизию rockpec. Если мой rockpec находится в VCS, и я помечаю конкретный коммит, то разве это не эффективно исправляет rockpec(s), включенный в этот коммит и, следовательно, версию? Более поздний пересмотр rockpec не может быть в помеченном коммите.
2. Как может lpeg быть в списке на luarocks, но не хватает rockspec?
3. Вики Луарока говорят, что scm должен использоваться вместо номера версии пакета, если вы хотите, чтобы ваш rockpec ссылался на HEAD. Но с тех пор HEAD постоянно меняется, и rockpec должен перечислить все файлы, казалось бы, нужно постоянно увеличивать revision номер scm rockpec, чтобы не отставать от любых добавленных или удаленных файлов. Можно обойти это, не используя номер ревизии вообще для scm rockpecs, и все же те, которые я вижу, имеют низкие номера ревизий (например, ldoc-scm-2.rockspec). Это ошибка?
4. Являются ли какие-либо из приведенных выше примеров лучшей практикой?

Answer 1

Для чего нужны версии Rockpec?

Версия Rockpec - это версия самого файла Rockpec. Предположим, вы выпустили Foo версии 1.0; вы создаете скалистые foo-1.0-1.rockspec, Позже вы узнаете, что для компиляции Foo 1.0 во FreeBSD вам необходимо передать дополнительную -D флаг; исходный код вообще не нуждается в изменениях. Вы редактируете rockpec, добавляя раздел переопределения платформы, и повторно отправляете его на https://luarocks.org/ как foo-1.0-2.rockspec,

Если мой rockpec находится в VCS, и я помечаю конкретный коммит, то разве это не эффективно исправляет rockpec(s), включенный в этот коммит и, следовательно, версию?

Да. Но это не проблема, потому что каменная спецификация, используемая при строительстве, не входит в исходную дистрибуцию. .src.rock файл представляет собой архив, содержащий представленные .rockspec файл и архив с исходным кодом (или извлечение исходного кода в подкаталоге, если rockpec использует протокол SCM, такой как git://).

Действительно, это приводит к проблеме "курица и яйцо" в том, что при проверке тега последней версии спекуляции для Foo 1.0 не существует. v1.0 вручную из Github, но это не ожидаемый рабочий процесс: при использовании LuaRocks пользователь обычно использует luarocks install foo; и если они захотят проверить спецификации скал для проекта, они либо посетят страницу Foo по адресу https://luarocks.org/, либо посмотрят на скалы, хранящиеся в HEAD, где люди в любом случае останавливаются первыми.

Обратите внимание, что похожая ситуация с яйцом и яйцом происходит, если кто-то хочет распространить архив с исходным кодом, содержащий скалистую спецификацию, а затем хочет установить архив source.url и его соответствующий source.md5 в скале. Наличие MD5 подразумевает, что сам Rockpes не может быть внутри тарбола. Один из способов обойти это просто избежать source.md5 поле, или пропустить скалистые при упаковке тарболла. Это та же ситуация, что и в случае с метаданными пакета дистрибутива Linux в вышестоящем архиве; это более очевидно здесь, потому что апстрим и упаковщик имеют тенденцию быть тем же самым человеком.

Как можно записать lpeg на luarocks, но не иметь скалистой спецификации?

Вероятно, потому что это редкий случай, когда апстрим и упаковщик не одно и то же лицо. Roberto Ierusalimschy выпустил lpeg, но по состоянию на декабрь 2016 года его спецификации были загружены Гэри Воганом.

[...] те, которые я вижу, имеют низкие номера ревизий (например, ldoc-scm-2.rockspec). Это ошибка?

Это может иметь много причин, и это может быть ошибкой или нет.

• Если Rockpec использует make встроенный, то scm rockpec, скорее всего, не изменится, когда файлы будут добавлены или удалены;
• Некоторые проекты просто не меняют свой набор файлов все так часто, поэтому ревизия остается низкой;
• Некоторые разработчики сохраняют свои scm горные породы в -0 (как в "не выпущенной ревизии") и никогда не загружайте их на https://luarocks.org/ (сохраняя только выпущенные версии). Таким образом, тот, который вы получаете, когда получаете git-ревизию, является правильным для этого снимка. Увеличение количества ревизий является ожидаемой практикой для скалистых спецификаций, опубликованных на https://luarocks.org/;
• Rockpec может быть действительно устаревшим, и тогда это ошибка.

Являются ли какие-либо из приведенных выше примеров лучшей практикой?

Объективно говоря, поскольку файл rockpec используется при запуске luarocks install foo это один внутри .src.rock Файл, хранящийся отдельно от исходных архивов, не имеет серьезных практических последствий в отношении того, где именно в исходном дереве разработчик хранит свои скалистые спецификации. Это вопрос личной организации.

Сохраняя последние scm у горной породы в корне есть небольшое преимущество, что она автоматически подхватывается luarocks make если кто-то хочет сделать сборку из локального проверенного дерева.

Но до тех пор, пока породы загружаются на сервер с luarocks upload fooопыт конечного пользователя будет одинаковым, независимо от того, где горные спекуляции находятся в исходном дереве.