`paths = requiredLuaModules (extraLibs ++ [ lua ] );` would discard lua
and so in absence of a propagated lua, the lua.withPackages would return
an empty bin/ directory.
I was working on lua tests, enabling nlua and I started overriding
postFixup, which removed the default phase for build-luarocks-package so
instead let's make it a proper phase.
the setup-hook checks if a derivation contains lua files matching
lua_path patterns. We use bash's globstar extension for that but
`**.lua` doesn't return files in subfolders, it has to be `**/*.lua`.
Adjust the pattern accordingly.
the 'http' package is an interesting one to test because all its lua
files are in a 'http' subfolder, ie., there is no share/lua/5.1/*.lua,
only share/lua/5.1/http/*.lua files unlike most packages. This tests we
can match those subfolders.
now that the lua interpreters include working directories with `./?.lua`
in LUA_PATH, the current test includes every derivation which quickly
becomes unreadable and unpractical.
The test is adapted to add a folder only if it can find lua files in the
subfolder.
In order to have the 'reset' LUA_PATH (aka `;;`) work, and for purity
reasons(removing /usr paths) we(I) decided to patch the lua interpreters default LUA_PATH.
Turns out the interpreters have different defaults and the patch was too
coarse.
There is smarter patching that can be done via LUA_ROOT.
Also luajit doesn't need patching at all since LUA_ROOT is set via the
build system.
somehow, between all my testing, all the code review, and my code being copy-pasted into
other people's PRs, noone noticed the glaring issue in the singular line of code i committed.
there was a missing negation. this has now been fixed.
There is an arbitrary mapping being done right now between
nixpkgs lua infrastructre and luarocks config schema.
This is confusing if you use lua so let's make it possible to use the
lua names in the nixpkgs, thanks to the lib.generators.toLua convertor.
The only nixpkgs thing to remember should be to put the config into `luarocksConfig`
`buildLuarocksPackage.extraVariables` should become `buildLuarocksPackage.luarocksConfig.variables`
it was used only once and complexifies the buildLuarocksPackage function uselessly.
because buildLuarocksPackage accepts ... args, it wont trigger eval failures but this may break out of tree packages where the build can't find the rockspec anymore. Specify the path via `knownRockspec` if that's the case.
* buildLuarocksPackage: save luarocks config as derivation
while debugging luarocks packages, it's exhausting to have to build
them, look at what random folder they've been built to finally look for
their config.
With this you can run
nix build lua51Packages.plenary-nvim.configFile -f .
and infer what luarocks will do.
* Update pkgs/development/interpreters/lua-5/build-luarocks-package.nix
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's switch to attrset-passing form, to provide some minimal level
of sanity-checking.
buildLuaPackage accesses lua.pkgs.luarocks, which became unspliced
at some point. Let's use callPackage to get it, so we can be sure
it will be spliced.
While searching for something different I wondered why there is a
trivial-builders.nix file next to the trivial-builders directory where
only tests live. Lets fix that.
it makes overriding easier, instead of having to know internals to
decide which of `sqlite = prev.luaLib.overrideLuarocks prev.sqlite (drv: {` or
`sqlite = prev.sqlite.overrideAttrs (drv: {` just use the latter
hopefully makes the output of nixpkgs-review more sensible.
Lua package sets are different and it makes more sense than for other
languages for packages to not be supported in specific package sets.
