| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Conflicts:
- pkgs/applications/graphics/seamly2d/default.nix
|
|
|
|
Changes: https://www.lua.org/work/diffs-lua-5.4.6-lua-5.4.7.html
|
|
Goal is to make generateLuarocksConfig appropriate in more scenarios, in my case, to generate rocks.nvim luarocks config
We override the luarocks default for rocks_subdir to avoid conflicts when creating lua environments but it is not appropriate for other scenarios
so let's not default to it in the "lib" function.
|
|
|
|
I tried using luaLib.generateLuarocksConfig outside nixpkgs, to generate a rocks.nvim config but it adds a `local_cache = ""` configuration line that is painful to remove so let's not add it in the first place, and let the caller set it if needed.
|
|
|
|
luarocks-nix store path was ..luarocks-version instead of ...luarocks-nix-version. This fixes it
|
|
so far we ignored propagated-build-inputs
|
|
When installing a lua package that depends on luarocks, luarocks was not
capable of recognizing the luarocks module: https://github.com/NixOS/nixpkgs/issues/316009 .
As explained here https://github.com/luarocks/luarocks/issues/1659,
luarocks needs a manifest to recognize the package.
I first attempted to generate a manifest with `luarocks-admin
make-manifest` on our current manual luarocks derivation but this ended
up being too hackish as the `make-manifest` requires a .rockspec or
.rock to work, which we had not.
It seemed simpled to just rename the current manual luarocks derivation to luarocks_bootstrap
in order to break cyclic dependencies in buildLuarocksPackage and add a
generated luarocks derivation. Previously it was impossible to test
luarocks because of the cyclic dependency but we will now be able to
test the generated derivation.
|
|
|
|
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.
|
|
This reverts commit ddefcf284ce57b2ebe042eba75feec70cfb19268.
Breakages need figuring out, reverting for now:
https://github.com/NixOS/nixpkgs/pull/303176#issuecomment-2053910614
|
|
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.
|
|
when LUA_PATH contains `;;`, it is replaced by `;LUA_PATH_DEFAULT;` in
lua 5.1:
Updated https://github.com/lua/lua/blob/69ea087dff1daba25a2000dfb8f1883c17545b7a/loadlib.c#L599
More recent versions might be smarter ?
https://github.com/lua/lua/blob/65b07dd53d7938a60112fc4473f5cad3473e3534/loadlib.c#L301
|
|
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.
|
|
imports to stop working
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`
|
|
makes overrideAttrs for lua packages even more powerful.
As a consequence, it simplifies the implementation of buildNeovimPlugin.
|
|
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.
|
|
better error message as well
extracted from https://github.com/NixOS/nixpkgs/pull/273342
written by heyarne
|
|
; Conflicts:
; pkgs/development/lua-modules/generated-packages.nix
; pkgs/development/lua-modules/overrides.nix
|
|
Before the change:
$ nix-instantiate --eval --strict --expr 'with import ./. {}; with corsix-th.luaEnv; [luaPath luaCpath]'
error:
error: attribute 'lib' missing
After the change:
$ nix-instantiate --eval --strict --expr 'with import ./. {}; with corsix-th.luaEnv; [luaPath luaCpath]'
[ "/nix/store/f17ah5zjri1yjacc1c50g9xlr8qqwbgh-lua-5.2.4-env/share/lua/5.2/?.lua;/nix/store/f17ah5zjri1yjacc1c50g9xlr8qqwbgh-lua-5.2.4-env/share/lua/5.2/?/init.lua" "/nix/store/f17ah5zjri1yjacc1c50g9xlr8qqwbgh-lua-5.2.4-env/lib/lua/5.2/?.so" ]
|
|
|
|
|
|
...into staging
|
|
* 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>
|
|
|
|
so that we can deprecate modules
|
|
|
|
|
|
These are often unneeded by the user.
|
|
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.
|
|
|
|
|
|
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
|
|
|
|
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.
|
|
follow up of https://github.com/NixOS/nixpkgs/pull/224553 where
some arguments got ignored whil they were before taken into account.
|
|
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
|
|
|
|
Also, make sure that "doc" outputs of different versions of lua are
co-installable, so user can install multiple manuals and read them
side-by-side.
|
|
...into staging
|
|
This reverts commit 0cd595cdb3b4f39ef5b903b64b45534ea9bc63ff.
It's causing build failures for knot-resolver and others.
Workaround for https://github.com/NixOS/nixpkgs/issues/223437
|
