2024-02-14 21:27:57 +01:00
# Lua {#lua}
2019-02-06 05:57:53 +01:00
2024-02-14 21:27:57 +01:00
## Using Lua {#lua-userguide}
2019-02-06 05:57:53 +01:00
2024-02-14 21:27:57 +01:00
### Overview of Lua {#lua-overview}
2019-02-06 05:57:53 +01:00
2020-06-06 19:53:58 +02:00
Several versions of the Lua interpreter are available: luajit, lua 5.1, 5.2, 5.3.
2020-06-07 20:12:56 +02:00
The attribute `lua` refers to the default interpreter, it is also possible to refer to specific versions, e.g. `lua5_2` refers to Lua 5.2.
2019-02-06 05:57:53 +01:00
Lua libraries are in separate sets, with one set per interpreter version.
The interpreters have several common attributes. One of these attributes is
`pkgs` , which is a package set of Lua libraries for this specific
interpreter. E.g., the `busted` package corresponding to the default interpreter
2020-06-06 19:53:58 +02:00
is `lua.pkgs.busted` , and the lua 5.2 version is `lua5_2.pkgs.busted` .
2019-02-06 05:57:53 +01:00
The main package set contains aliases to these package sets, e.g.
2020-06-06 19:53:58 +02:00
`luaPackages` refers to `lua5_1.pkgs` and `lua52Packages` to
`lua5_2.pkgs` .
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
### Installing Lua and packages {#installing-lua-and-packages}
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
#### Lua environment defined in separate `.nix` file {#lua-environment-defined-in-separate-.nix-file}
2019-02-06 05:57:53 +01:00
Create a file, e.g. `build.nix` , with the following expression
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```nix
with import < nixpkgs > {};
2020-06-06 19:53:58 +02:00
lua5_2.withPackages (ps: with ps; [ busted luafilesystem ])
2019-02-06 05:57:53 +01:00
```
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
and install it in your profile with
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```shell
nix-env -if build.nix
```
Now you can use the Lua interpreter, as well as the extra packages (`busted`,
`luafilesystem` ) that you added to the environment.
2021-06-05 21:22:45 +02:00
#### Lua environment defined in `~/.config/nixpkgs/config.nix` {#lua-environment-defined-in-.confignixpkgsconfig.nix}
2019-02-06 05:57:53 +01:00
If you prefer to, you could also add the environment as a package override to the Nixpkgs set, e.g.
using `config.nix` ,
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```nix
{ # ...
packageOverrides = pkgs: with pkgs; {
2020-06-07 20:12:56 +02:00
myLuaEnv = lua5_2.withPackages (ps: with ps; [ busted luafilesystem ]);
2019-02-06 05:57:53 +01:00
};
}
```
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
and install it in your profile with
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```shell
nix-env -iA nixpkgs.myLuaEnv
```
2021-03-14 11:49:35 +01:00
The environment is installed by referring to the attribute, and considering
2019-02-06 05:57:53 +01:00
the `nixpkgs` channel was used.
2021-06-05 21:22:45 +02:00
#### Lua environment defined in `/etc/nixos/configuration.nix` {#lua-environment-defined-in-etcnixosconfiguration.nix}
2019-02-06 05:57:53 +01:00
For the sake of completeness, here's another example how to install the environment system-wide.
```nix
{ # ...
environment.systemPackages = with pkgs; [
(lua.withPackages(ps: with ps; [ busted luafilesystem ]))
];
}
```
2021-06-05 21:22:45 +02:00
### How to override a Lua package using overlays? {#how-to-override-a-lua-package-using-overlays}
2019-03-07 09:17:18 +01:00
Use the following overlay template:
```nix
2020-06-06 19:53:58 +02:00
final: prev:
2019-03-07 09:17:18 +01:00
{
lua = prev.lua.override {
packageOverrides = luaself: luaprev: {
luarocks-nix = luaprev.luarocks-nix.overrideAttrs(oa: {
2020-06-06 19:53:58 +02:00
pname = "luarocks-nix";
2019-03-07 09:17:18 +01:00
src = /home/my_luarocks/repository;
});
};
luaPackages = lua.pkgs;
}
```
2021-06-05 21:22:45 +02:00
### Temporary Lua environment with `nix-shell` {#temporary-lua-environment-with-nix-shell}
2019-02-06 05:57:53 +01:00
There are two methods for loading a shell with Lua packages. The first and recommended method
is to create an environment with `lua.buildEnv` or `lua.withPackages` and load that. E.g.
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```sh
$ nix-shell -p 'lua.withPackages(ps: with ps; [ busted luafilesystem ])'
```
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
opens a shell from which you can launch the interpreter
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```sh
[nix-shell:~] lua
```
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
The other method, which is not recommended, does not create an environment and requires you to list the packages directly,
```sh
$ nix-shell -p lua.pkgs.busted lua.pkgs.luafilesystem
```
Again, it is possible to launch the interpreter from the shell.
The Lua interpreter has the attribute `pkgs` which contains all Lua libraries for that specific interpreter.
2024-02-14 21:27:57 +01:00
## Developing with lua {#lua-developing}
2019-02-06 05:57:53 +01:00
Now that you know how to get a working Lua environment with Nix, it is time
to go forward and start actually developing with Lua. There are two ways to
package lua software, either it is on luarocks and most of it can be taken care
of by the luarocks2nix converter or the packaging has to be done manually.
Let's present the luarocks way first and the manual one in a second time.
2021-06-05 21:22:45 +02:00
### Packaging a library on luarocks {#packaging-a-library-on-luarocks}
2019-02-06 05:57:53 +01:00
2021-12-09 18:23:52 +01:00
[Luarocks.org ](https://luarocks.org/ ) is the main repository of lua packages.
2023-04-14 22:02:17 +02:00
The site proposes two types of packages, the `rockspec` and the `src.rock`
2020-06-06 19:53:58 +02:00
(equivalent of a [rockspec ](https://github.com/luarocks/luarocks/wiki/Rockspec-format ) but with the source).
2019-02-06 05:57:53 +01:00
2023-04-14 22:02:17 +02:00
Luarocks-based packages are generated in [pkgs/development/lua-modules/generated-packages.nix ](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/generated-packages.nix ) from
the whitelist maintainers/scripts/luarocks-packages.csv and updated by running
2023-10-29 21:02:55 +01:00
the package `luarocks-packages-updater` :
2023-04-14 22:02:17 +02:00
```sh
2023-10-29 21:02:55 +01:00
nix-shell -p luarocks-packages-updater --run luarocks-packages-updater
2023-04-14 22:02:17 +02:00
```
2019-02-06 05:57:53 +01:00
2020-06-06 19:53:58 +02:00
[luarocks2nix ](https://github.com/nix-community/luarocks ) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
The automation only goes so far though and some packages need to be customized.
2023-04-14 22:02:17 +02:00
These customizations go in [pkgs/development/lua-modules/overrides.nix ](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/overrides.nix ).
2021-08-03 00:24:05 +02:00
For instance if the rockspec defines `external_dependencies` , these need to be manually added to the overrides.nix.
2019-02-06 05:57:53 +01:00
2020-06-06 19:53:58 +02:00
You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME` .
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
#### Packaging a library manually {#packaging-a-library-manually}
2019-02-06 05:57:53 +01:00
You can develop your package as you usually would, just don't forget to wrap it
within a `toLuaModule` call, for instance
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```nix
mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
```
2020-06-06 19:53:58 +02:00
There is also the `buildLuaPackage` function that can be used when lua modules
are not packaged for luarocks. You can see a few examples at `pkgs/top-level/lua-packages.nix` .
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
## Lua Reference {#lua-reference}
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
### Lua interpreters {#lua-interpreters}
2019-02-06 05:57:53 +01:00
2021-08-03 00:24:05 +02:00
Versions 5.1, 5.2, 5.3 and 5.4 of the lua interpreter are available as
respectively `lua5_1` , `lua5_2` , `lua5_3` and `lua5_4` . Luajit is available too.
2020-06-06 19:53:58 +02:00
The Nix expressions for the interpreters can be found in `pkgs/development/interpreters/lua-5` .
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
#### Attributes on lua interpreters packages {#attributes-on-lua-interpreters-packages}
2019-02-06 05:57:53 +01:00
Each interpreter has the following attributes:
2020-06-06 19:53:58 +02:00
- `interpreter` . Alias for `${pkgs.lua}/bin/lua` .
2019-05-18 14:51:16 +02:00
- `buildEnv` . Function to build lua interpreter environments with extra packages bundled together. See section *lua.buildEnv function* for usage and documentation.
2019-02-06 05:57:53 +01:00
- `withPackages` . Simpler interface to `buildEnv` .
- `pkgs` . Set of Lua packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides` .
2021-06-05 21:22:45 +02:00
#### `buildLuarocksPackage` function {#buildluarockspackage-function}
2019-02-06 05:57:53 +01:00
2023-07-09 17:45:02 +02:00
The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
2019-02-06 05:57:53 +01:00
The following is an example:
```nix
2020-06-06 19:53:58 +02:00
luaposix = buildLuarocksPackage {
pname = "luaposix";
version = "34.0.4-1";
2019-02-06 05:57:53 +01:00
src = fetchurl {
2020-06-06 19:53:58 +02:00
url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
doc: use sri hash syntax
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
2022-12-03 20:49:00 +01:00
hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
2019-02-06 05:57:53 +01:00
};
2020-06-06 19:53:58 +02:00
disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
propagatedBuildInputs = [ bit32 lua std_normalize ];
Nix docs: remove `with lib;` from example code
Following [Best Practices](https://nix.dev/guides/best-practices#with-scopes),
`with` is a problematic language construction and should be avoided.
Usually it is employed like a "factorization": `[ X.A X.B X.C X.D ]` is written
`with X; [ A B C D ]`.
However, as shown in the link above, the syntatical rules of `with` are not so
intuitive, and this "distributive rule" is very selective, in the sense that
`with X; [ A B C D ]` is not equivalent to `[ X.A X.B X.C X.D ]`.
However, this factorization is still useful to "squeeze" some code, especially
in lists like `meta.maintainers`.
On the other hand, it becomes less justifiable in bigger scopes. This is
especially true in cases like `with lib;` in the top of expression and in sets
like `meta = with lib; { . . . }`.
That being said, this patch removes most of example code in the current
documentation.
The exceptions are, for now
- doc/functions/generators.section.md
- doc/languages-frameworks/coq.section.md
because, well, they are way more complicated, and I couldn't parse them
mentally - yet another reason why `with` should be avoided!
2024-03-06 12:51:54 +01:00
meta = {
2020-06-06 19:53:58 +02:00
homepage = "https://github.com/luaposix/luaposix/";
description = "Lua bindings for POSIX";
Nix docs: remove `with lib;` from example code
Following [Best Practices](https://nix.dev/guides/best-practices#with-scopes),
`with` is a problematic language construction and should be avoided.
Usually it is employed like a "factorization": `[ X.A X.B X.C X.D ]` is written
`with X; [ A B C D ]`.
However, as shown in the link above, the syntatical rules of `with` are not so
intuitive, and this "distributive rule" is very selective, in the sense that
`with X; [ A B C D ]` is not equivalent to `[ X.A X.B X.C X.D ]`.
However, this factorization is still useful to "squeeze" some code, especially
in lists like `meta.maintainers`.
On the other hand, it becomes less justifiable in bigger scopes. This is
especially true in cases like `with lib;` in the top of expression and in sets
like `meta = with lib; { . . . }`.
That being said, this patch removes most of example code in the current
documentation.
The exceptions are, for now
- doc/functions/generators.section.md
- doc/languages-frameworks/coq.section.md
because, well, they are way more complicated, and I couldn't parse them
mentally - yet another reason why `with` should be avoided!
2024-03-06 12:51:54 +01:00
maintainers = with lib.maintainers; [ vyp lblasc ];
2020-06-06 19:53:58 +02:00
license.fullName = "MIT/X11";
2019-02-06 05:57:53 +01:00
};
};
```
The `buildLuarocksPackage` delegates most tasks to luarocks:
2020-06-06 19:53:58 +02:00
* it adds `luarocks` as an unpacker for `src.rock` files (zip files really).
2022-10-25 22:34:32 +02:00
* `configurePhase` writes a temporary luarocks configuration file which location
2019-02-06 05:57:53 +01:00
is exported via the environment variable `LUAROCKS_CONFIG` .
2020-06-06 19:53:58 +02:00
* the `buildPhase` does nothing.
2019-02-06 05:57:53 +01:00
* `installPhase` calls `luarocks make --deps-mode=none --tree $out` to build and
install the package
* In the `postFixup` phase, the `wrapLuaPrograms` bash function is called to
wrap all programs in the `$out/bin/*` directory to include `$PATH`
environment variable and add dependent libraries to script's `LUA_PATH` and
`LUA_CPATH` .
2024-02-11 19:36:56 +01:00
It accepts as arguments:
* 'luarocksConfig': a nix value that directly maps to the luarocks config used during
the installation
2020-06-06 19:53:58 +02:00
By default `meta.platforms` is set to the same value as the interpreter unless overridden otherwise.
2019-02-06 05:57:53 +01:00
2021-06-05 21:22:45 +02:00
#### `buildLuaApplication` function {#buildluaapplication-function}
2019-02-06 05:57:53 +01:00
The `buildLuaApplication` function is practically the same as `buildLuaPackage` .
The difference is that `buildLuaPackage` by default prefixes the names of the packages with the version of the interpreter.
Because with an application we're not interested in multiple version the prefix is dropped.
2021-06-05 21:22:45 +02:00
#### lua.withPackages function {#lua.withpackages-function}
2019-02-06 05:57:53 +01:00
2019-05-18 14:51:16 +02:00
The `lua.withPackages` takes a function as an argument that is passed the set of lua packages and returns the list of packages to be included in the environment.
Using the `withPackages` function, the previous example for the luafilesystem environment can be written like this:
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```nix
lua.withPackages (ps: [ps.luafilesystem])
```
`withPackages` passes the correct package set for the specific interpreter version as an argument to the function. In the above example, `ps` equals `luaPackages` .
2024-02-14 21:27:57 +01:00
But you can also easily switch to using `lua5_1` :
2021-06-05 21:22:45 +02:00
2019-02-06 05:57:53 +01:00
```nix
2024-02-14 21:27:57 +01:00
lua5_1.withPackages (ps: [ps.lua])
2019-02-06 05:57:53 +01:00
```
2024-02-14 21:27:57 +01:00
Now, `ps` is set to `lua5_1.pkgs` , matching the version of the interpreter.
2019-02-06 05:57:53 +01:00
2024-02-14 21:27:57 +01:00
### Lua Contributing guidelines {#lua-contributing}
2019-02-06 05:57:53 +01:00
Following rules should be respected:
2020-06-06 19:53:58 +02:00
* Commit names of Lua libraries should reflect that they are Lua libraries, so write for example `luaPackages.luafilesystem: 1.11 -> 1.12` .