outPath is not right when __contentAddressed=true

[YuMingLiao]

I was adding __contentAddressed=true to snack, a nix-based bulid tool.
"Fix IFD with CA derivations" (#5807) has dealt with some bugs already, so I just need to upgrade nix to fix a bug earlier.

However, now it's outPath that has problems with ca-derivations.

to install snack (after adding __contentAddressed=true in derivations in code):
nix-env -f ./default.nix -iA snack-exe

warning: unknown experimental feature 'ca-references'
replacing old 'snack'
installing 'snack'
error: path '/1xc764a5cm2060n3jfdkhm8nyn8x8hhlr6nbxlhaxhn8dwgx600l' is not in the Nix store

       at /nix/store/7ik44ld5fa8i66sf3737y3jj92c22i03-nixos/nixos/lib/customisation.nix:204:13:

          203|             drvPath = assert condition; drv.${outputName}.drvPath;
          204|             outPath = assert condition; drv.${outputName}.outPath;
             |             ^
          205|           };

Expected behavior

Get right outPath like /nix/store/xxx and run smoothly like non-ca derivations.

nix-env --version output
nix-env (Nix) 2.7.0

** thoughts **
I think it's somewhere about installation in nix-env code that called customisation.nix and cause this. but nix-env ... --show-trace didn't give more infos.

[thufschmitt]

That’s a fundamental design tradeof with CA derivations: we can’t know the out path until we’ve built it (hence the weird placeholder).

But indeed, nix-env is failing and it shouldn’t. I can replicate it without snack:

$ NIX_PROFILE=$PWD/profile nix-env -i -f '<nixpkgs>' --arg config '{ contentAddressedByDefault = true; }' -A hello
installing 'hello-2.12'
error: path '/169040rvrkfnqnnddgmz3prbcwnk3sy62kj2x0zyhhynwgng0ziv' is not in the Nix store

       at /nix/store/m0mp896mn6np6bvkrrljcg1ax416p670-f71alr07xb2swc37fiqjr5h416qcs6wr-source/lib/customisation.nix:157:13:

          156|             drvPath = assert condition; drv.${outputName}.drvPath;
          157|             outPath = assert condition; drv.${outputName}.outPath;
             |             ^
          158|           };

[SuperSandro2000]

nix eval also creates rather unexpected outputs:

➜ nix eval /etc/nixos#nixosConfigurations.$HOSTNAME.config.system.build.toplevel
/15b59kqr4l82wj838xd7ca01wvk4ap1vmvfrp1a9qnjnz4a9wdvb

just because there is somewhere a content addressed derivation evolved.

[SuperSandro2000]

Can I in some way force the drv to be built? Maybe with IFD?

[Ericson2314]

@SuperSandro2000 that is again intention --- a placeholder to be replaced with the store path. You can force it to be a store path with IFD and a wrapper derivation and echo ${placeholder} > out, but do you actually need this?

[SuperSandro2000]

I think I would be less confused if the slash at the beginning wouldn't be there or the suffix would be something lika ca- or something.

but do you actually need this?

I am evaluating my config locally, copying the drv to the remote and then building it there.

I think I solved it in my deployment script by actually evaluating .drvPath which nix eval should probably fall back to in case it would generate the placeholder.

 ▶ nix eval .#nixosConfigurations.hydrogen.config.system.build.toplevel
/0mpdq8iznha8dkm59vm1g4rb2rvrjcwgk0y6lqk8ijw5sp7kfpwi

 ▶ nix eval .#nixosConfigurations.hydrogen.config.system.build.toplevel.drvPath
/nix/store/lx3fwhmv63859n287rwcn7b6s6r1xcj1-nixos-system-hydrogen-23.11.drv

[SuperSandro2000]

--apply 'x: x.drvPath' apply fixes my nix eval issue. Going to throw that into my aliases for the time being.

[yshui]

This is also a problem for system.extraDependencies, which complains:

error: A definition for option `system.extraDependencies."[definition 1-entry 9]"' is not of type `path in the Nix store'.