which contains lua shell utilities that can be reused during the
creation of an environment.
Makes sense because the generation of LUA_PATH is a bit different than
other ecosystems.
`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.
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>
