The LuaRocks.org repository allows for each user to published their own collection of rocks. Since LuaRocks 3, this concept of per-user rocks has been integrated into the tool, in the form of namespaces.
What you can do with namespaces:
- Install packages using a namespace:
luarocks install my_user/my_rock
- Depend on a specific namespaced version of a rock in your rockspec:
dependencies = { "my_user/my_rock > 2.0" }
LuaRocks has always supported multiple repositories, which can be set in the
config file with the rocks_servers entry. A
repository is an address (a local directory or a remote URL) where LuaRocks
can find a manifest-5.x file and .rock and .rockspec files. We also call
such repository a "manifest", for short.
The LuaRocks.org website features a root manifest at
https://luarocks.org as well as per-user manifests at
https://luarocks.org/manifests/<your-user-name>. Entries in the root
manifest are operated in a first-come first-served manner, but even if someone
else has already taken a rock name, you can upload your own version of it to
your user manifest. You can refer to a per-user manifest the same way as any
other rocks server, adding to your configuration or using it with the--server flag. This means that you were always able to install your own
version of a rock using a command such as luarocks install <my-rock> --server=https://luarocks.org/manifests/<your-user-name>. However, you could
not specifically depend on it from another rockspec, and once installed, the
information that this rock came from a specific manifest was lost. With
namespaces, now you can!
All luarocks commands that accept a rock name as command line argument can
now take a namespaced variant:
luarocks install my_user/my_rock
LuaRocks will take your rocks_trees configuration and search for namespaced
manifests on each entry: for example, given the default server
https://luarocks.org it will look in
https://luarocks.org/manifests/my_user.
When installing, LuaRocks will internally store the information that this copy
of my_rock came from the my_user namespace, so it will be able to use that
information when another rockspec specifically asks for my_user/my_rock in
its dependencies. (The namespace information is stored in a separate
rock_namespace metadata file, at
lib/luarocks/rocks-5.x/my_rock/1.0-1/rock_namespace, relative to your local
rocks tree.)
A namespaced package can stand for a non-namespaced one. If you have
my_user/my_rock 1.0 installed and a rock depends on my_rock 1.0, the
installed rock will satisfy the dependency.
The opposite is not true: if you have my_rock 1.0 installed but that did not
come from a my_user namespace, it will not satisfy a dependency for
my_user/my_rock.
You cannot have two rocks with the same name and version but different namespaces installed at the same time in the same local rocks tree.