Change:
Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?
I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.

Discussion:
# Appended to the generated luarocks config , extraConfig ? "" # Inserted into the generated luarocks config in the "variables" table <del> , extraVariables ? "" </del> <ins> , extraVariables ? {} </ins> # The two above arguments have access to builder variables -- e.g. to $out # relative to srcRoot, path to the rockspec to use when using rocks

# luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

-- Some needed machinery to handle multiple-output external dependencies, -- as per https://github.com/luarocks/luarocks/issues/766 ${lib.optionalString (lib.length depVariables > 0) '' <del> ${lib.concatStringsSep "n  " depVariables}''} ${extraVariables} </del> <ins> ${lib.concatStringsSep "n  " depVariables}''} ${extraVariablesStr} </ins> } ${extraConfig} '';

externalDeps' = lib.filter (dep: !lib.isDerivation dep) externalDeps; in toLuaModule ( lua.stdenv.mkDerivation ( <del> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps"] // { </del> <ins> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps" "extraVariables"] // { </ins> name = namePrefix + name;

LUAROCKS="$LUAROCKS --verbose" fi <del> patchShebangs . </del> runHook postBuild '';

runHook postInstall ''; <ins> checkPhase = attrs.checkPhase or '' runHook preCheck $LUAROCKS test runHook postCheck ''; </ins> passthru = { inherit lua; # The lua interpreter inherit externalDeps;

}); luadbi-mysql = super.luadbi-mysql.override({ <del> extraVariables = '' -- Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR='${pkgs.libmysqlclient}/include/mysql'; MYSQL_LIBDIR='${pkgs.libmysqlclient}/lib/mysql'; ''; </del> <ins> extraVariables = { # Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR="${pkgs.libmysqlclient}/include/mysql"; MYSQL_LIBDIR="${pkgs.libmysqlclient}/lib/mysql"; }; </ins> buildInputs = [ pkgs.mysql.client pkgs.libmysqlclient