-
Notifications
You must be signed in to change notification settings - Fork 0
Rock file format
This page describes the .rock file format used by LuaRocks.
Note that there are different types of rocks.
-
.rock and .rockspec filenames must be all-lowercase
-
Rock names must follow the format "$NAME-$VERSION-$REVISION.$PLATFORM.rock", where:
-
$NAME is an arbitrary name (matchable via
"[a-z0-9_-]+") -
$VERSION is a version number parseable by LuaRocks (e.g. "1.0", "2.1beta1", "scm" for git-HEAD/svn-master rockspecs)
-
$REVISION is the rockspec revision number, a positive integer
-
$PLATFORM must follow the format "$OS-$ARCH", where:
- $OS is an operating system identifier known by LuaRocks
- $ARCH is a hardware architecture identifier known by LuaRocks
A binary rock must contain at its root the rockspec file. For a rock called myrock-1.0-1.src.rock it would be called:
-
myrock-1.0-1.rockspec- the [rockspec file](Rockspec format) in the archive root
Additionally, it must contain the sources:
- If the
source.urlfield is specified using a file download protocol-type URL (http://,https://,file://and so on) pointing to the source archive (or source file in case of a single-file rock), the rock should contain the product of downloading this URL.- For example, a source rock may contain two files:
myrock-1.0-1.rockspecandmyrock-1.0.tar.gz
- For example, a source rock may contain two files:
- If the
source.urlfield is specified using a Source Control Manager (SCM) protocol-type URL (git://,hg://,svn://and so on), the rock should contain the corresponding checked-out sources. The SCM metadata (e.g. the.gitdirectory) does not need to be present. (Note: This is not specific to "scm" rocks that point to in-development repositories; a stable-version rockspec may use a SCM-based URL and an SCM tag withsource.tagin the rockspec to point to a release version).- For example, a source rock may contain at the root the rockspec
myrock-1.0-1.rockspecand a directorymyrockthat would be the result ofgit clone https://github.com/example/myrock
- For example, a source rock may contain at the root the rockspec
A binary rock must contain at its root two files. For a rock called myrock-1.0-1.linux-x86.rock they would be called:
-
myrock-1.0-1.rockspec- the [rockspec file](Rockspec format) in the archive root -
rock_manifest- a [rock manifest file](Rock manifest file format)
These standard directories are handled specially:
-
lib/- a directory containing binary modules (the contents of this directory are files that go into$PREFIX/lib/lua/5.x/in a vanilla Lua installation on Unix). The directory structure inside this directory is replicated when installing. -
lua/- a directory containing Lua modules (the contents of this directory are files that go into$PREFIX/share/lua/5.x/in a vanilla Lua installation on Unix). The directory structure inside this directory is replicated when installing. -
bin/- a directory containing executable Lua scripts (the contents of this directory are files that go into$PREFIX/bin/in a vanilla Lua installation on Unix) -
doc/ordocs/- documentation files - if present, their contents are listed when runningluarocks doc. The directory structure inside this directory is replicated when installing.
Any additional directories in the .rock file are copied verbatim (including subdirectories) to $ROCK_TREE/lib/luarocks/rocks-5.x/myrock/1.0-1/ (common directories are tests, samples, examples, etc.
Pure-Lua rocks are identical to binary rocks, except that they don't have a lib/ directory containing binary modules. When a rock contains only lua/ files and no lib/ files, it automatically gains the .all.rock file extension. If the rock is platform-specific, the packager may rename the file to the proper platform, or specify the list of supported platforms in the supported_platforms table of the rockspec.