Change:
{ lib <del> , pkgs </del> , stdenvNoCC , fetchFromGitHub , pkgsCross <ins> , stdenv , bash </ins> }: stdenvNoCC.mkDerivation (finalAttrs: let <del> system = lib.toLower stdenvNoCC.targetPlatform.uname.system; # DXVK needs to be a separate derivation because it’s actually a set of DLLs for Windows that # needs to be built with a cross-compiler. dxvk32 = pkgsCross.mingw32.callPackage ./dxvk.nix { inherit (finalAttrs) src version dxvkPatches; }; dxvk64 = pkgsCross.mingwW64.callPackage ./dxvk.nix { inherit (finalAttrs) src version dxvkPatches; }; # Split out by platform to make maintenance easy in case supported versions on Darwin and other # platforms diverge (due to the need for Darwin-specific patches that would fail to apply). # Should that happen, set `darwin` to the last working `rev` and `hash`. srcs = rec { darwin = { rev = "v${finalAttrs.version}"; hash = "sha256-T93ZylxzJGprrP+j6axZwl2d3hJowMCUOKNjIyNzkmE="; version = "1.10.3"; }; default = { rev = "v${finalAttrs.version}"; hash = "sha256-mboVLdPgZMzmqyeF0jAloEz6xqfIDiY/X98e7l2KZnw="; version = "2.0"; }; }; </del> <ins> dxvk32 = if stdenv.isDarwin then pkgsCross.mingw32.dxvk_1 else pkgsCross.mingw32.dxvk_2; dxvk64 = if stdenv.isDarwin then pkgsCross.mingwW64.dxvk_1 else pkgsCross.mingwW64.dxvk_2; </ins> in { name = "dxvk"; <del> inherit (srcs."${system}" or srcs.default) version; src = fetchFromGitHub { owner = "doitsujin"; repo = "dxvk"; inherit (srcs."${system}" or srcs.default) rev hash; }; # Override this to patch DXVK itself (rather than the setup script). dxvkPatches = lib.optionals stdenvNoCC.isDarwin [ # Patch DXVK to work with MoltenVK even though it doesn’t support some required features. # Some games work poorly (particularly Unreal Engine 4 games), but others work pretty well. ./darwin-dxvk-compat.patch # Use synchronization primitives from the C++ standard library to avoid deadlocks on Darwin. # See: https://www.reddit.com/r/macgaming/comments/t8liua/comment/hzsuce9/ ./darwin-thread-primitives.patch ]; </del> <ins> inherit (dxvk64) version; </ins> outputs = [ "out" "bin" "lib" ]; <del> # Also copy `mcfgthread-12.dll` due to DXVK’s being built in a MinGW cross environment. patches = [ ./mcfgthread.patch ]; </del> <ins> dontUnpack = true; </ins> dontConfigure = true; dontBuild = true; installPhase = '' mkdir -p $out/bin $bin $lib <del> # Replace both basedir forms to support both DXVK 2.0 and older versions. substitute setup_dxvk.sh $out/bin/setup_dxvk.sh  </del> <ins> substitute ${./setup_dxvk.sh} $out/bin/setup_dxvk.sh  --subst-var-by bash ${bash}  --subst-var-by dxvk32 ${dxvk32}  --subst-var-by dxvk64 ${dxvk64}  </ins> --subst-var-by mcfgthreads32 "${pkgsCross.mingw32.windows.mcfgthreads}"  <del> --subst-var-by mcfgthreads64 "${pkgsCross.mingwW64.windows.mcfgthreads}"  --replace 'basedir=$(dirname "$(readlink -f $0)")' "basedir=$bin"  --replace 'basedir="$(dirname "$(readlink -f "$0")")"' "basedir=$bin" </del> <ins> --subst-var-by mcfgthreads64 "${pkgsCross.mingwW64.windows.mcfgthreads}" </ins> chmod a+x $out/bin/setup_dxvk.sh declare -A dxvks=( [x32]=${dxvk32} [x64]=${dxvk64} ) for arch in "''${!dxvks[@]}"; do

Discussion:
In future releases of dxvk the setup script won't be included anymore so this issue is just to notify so something can be figured out for how the nix package should handle it beforehand. (Hope such an issue is okay) See
CC
Thanks for the heads up. The DLLs are already available via a output, but this will break anyone’s set up that relies on . A short term solution would be to vendor the script. Longer term, it would be ideal if there were a way to declaratively create and manage a Wine prefix.
1 has been released with the script removed
I saw that. It can also build natively on Linux, which is interesting. I need to think about how I want to do things and maybe see what other distributions that package it are doing.
God speed
There is a nix-gaming repository that contains such derivation: It also handles vkd3d-proton:
One approach I’m considering is splitting dxvk into dxvk110 (for Darwin and hardware no longer supported by 2.0) and dxvk2x (or just dxvk_2, not sure). The plain DXVK derivation could continue to provide the script (most likely copied from before upstream removed it) while the versioned ones would be built for the native platform only (Linux and Windows). Well, I guess if it builds on Darwin, I can set the platform to then mark it broken on Darwin. I doubt DXVK 2.0 will work on Darwin any time soon. There are a number of extensions DXVK needs that aren’t implemented yet in MoltenVK, and since DXVK is always adding and using new ones, it’s a moving target.
I created to add the script and bump DXVK. It also exposes native builds on Linux.