dotnet: fetch-deps permission denied when moving into Nix store

[Smaug123]

Describe the bug

Some time in the last week, the passthru fetch-deps for NuGet has started doing this:

  Restored /private/tmp/tmp.GGeTvdwebS/v5y700rk8i6d4jk60aa2ydb45pn3l6lp-source/WoofWare.Myriad.Plugins/WoofWare.Myriad.Plugins.fsproj (in 147 ms).
  Restored /private/tmp/tmp.GGeTvdwebS/v5y700rk8i6d4jk60aa2ydb45pn3l6lp-source/ConsumePlugin/ConsumePlugin.fsproj (in 145 ms).
  Restored /private/tmp/tmp.GGeTvdwebS/v5y700rk8i6d4jk60aa2ydb45pn3l6lp-source/WoofWare.Myriad.Plugins.Attributes/WoofWare.Myriad.Plugins.Attributes.fsproj (in 145 ms).
  Restored /private/tmp/tmp.GGeTvdwebS/v5y700rk8i6d4jk60aa2ydb45pn3l6lp-source/WoofWare.Myriad.Plugins.Test/WoofWare.Myriad.Plugins.Test.fsproj (in 154 ms).
Finished dotnetConfigureHook
configurePhase completed in 1 minutes 3 seconds
fantomas 6.3.12 is available at https://api.nuget.org/v3-flatcontainer/fantomas/6.3.12/fantomas.6.3.12.nupkg, but was restored from null
fsharp-analyzers 0.27.0 is available at https://api.nuget.org/v3-flatcontainer/fsharp-analyzers/0.27.0/fsharp-analyzers.0.27.0.nupkg, but was restored from null
mv: replace '/nix/store/v5y700rk8i6d4jk60aa2ydb45pn3l6lp-source/nix/deps.nix', overriding mode 0444 (r--r--r--)? ^C

In my non-interactive pipelines, this was immediately fatal (https://github.com/Smaug123/WoofWare.Myriad/actions/runs/10866966813/job/30155191667). Nixpkgs revision 9bb1e7571aadf31ddb4af77fc64b2d59580f9a39 was fine; revision 01f064c99c792715054dc7a70e4c1626dbbec0c3 had the problem.

Steps To Reproduce

Steps to reproduce the behavior:

1. git clone https://github.com/Smaug123/WoofWare.DotnetRuntimeLocator and git checkout a72db2a820fe92080018d623893a48a54f96038b
2. nix build .#default.passthru.fetch-deps && ./result

Expected behavior

The usual upgrade, resulting in a deps.nix file in in /tmp.

Notify maintainers

@corngood

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.5.0, macOS 14.5`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

---

Add a :+1: reaction to issues you find important.

[corngood]

This is sort-of fixed by #336824, but you have to explicitly pass in the output path, e.g. ./result nix/deps.nix.

          defaultDepsFile =
            # Wire in the depsFile such that running the script with no args
            # runs it agains the correct deps file by default.
            # Note that toString is necessary here as it results in the path at
            # eval time (i.e. to the file in your local Nixpkgs checkout) rather
            # than the Nix store path of the path after it's been imported.
            if lib.isPath nugetDeps && !lib.isStorePath nugetDeps then
              toString nugetDeps
            else
              ''$(mktemp -t "${finalAttrs.pname or finalPackage.name}-deps-XXXXXX.nix")'';

In a flake, everything is evaluated from the store, so nugetDeps is e.g. /nix/store/5hxbzwsgzjp0z6z7ff2g9b4r16pffr3d-source/nix/deps.nix. The code above is supposed to take care of that, but apparently lib.isStorePath only returns true for paths whose immediate parent is the store directory (so like /nix/store/a, but not /nix/store/a/b).

I'd love this to find the output path properly with flakes, but I'm not sure that's possible if you're evaluating something immutable. I went looking for discussion of this in relation to updateScript, since it would have the same problem, and the only thing I found was: https://discourse.nixos.org/t/how-can-i-run-the-updatescript-of-personal-packages/25274/2. They ended up using flake-compat, which might be the only way...

[Smaug123]

That's a perfectly fine restriction in my book! I'll leave this open and retry it when #336824 goes in.

[Smaug123]

Lovely, that fix worked for me!