nix-shell creates invalid store paths which is inconsitent with nix-build behavior

[jraygauthier]

When I use nix-shell to debug a package, it creates an invalid path in the store which
couldn't / wouldn't be reused when I perform subsequent nix-build. Here is a very simple
example of the problem:

nix-shell '<nixpkgs>' -A hello --pure
genericBuild

The build is successful and installed in /nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9/bin/hello store path.

I then validate the store path with the following command:

nix-store --verify-path /nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9

resulting in:

error: path `/nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9' is not valid

Now, I try to use the exact same command, but with nix-build.

nix-build '<nixpkgs>' -A hello --pure

Again, the build is successful and installed in /nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9/bin/hello store path.

Performing yet again the store path validation

nix-store --verify-path /nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9

now, everything seems fine (no stderr).

Note that also that I would have assumed that as the path /nix/store/w08118q0kp26qdcz5cdl2rx6chghawam-hello-2.9 was already in the store, it should have been
used by the nix-build command instead of restarting from scratch.

Is there something I do not understand there? Is there some other command to perform after
genericBuild to register the path with the nix store?

To have this kind of workflow available would be of great help when you want to quickly experiment
on the sources of a package iteratively using the incremental build capability of nix-shell and once
satisfied, test the integration of this expression in a the system as a whole using nix-build in combination with myEnvFun without a whole restart of the package you just compiled minutes ago.

I know this kind of workflow may be reproduced in some way using only myEnvFun but then:

• myEnvFun target the development on a single package.
• You have to resort to direct use of the specific builder and parametrize it so that it matches current
  system configuration. Lead to stuff like
  cabal configure --enable-shared --enable-executable-dynamic --allow-newer.
• You still have to find a yet specific way to install this package so that other packages
  are able to interact with it. This may imply setting some LD paths, changing PATH
  , registering a library to the compiler, etc... In other words, all of the stuff that comes
  for free using nix-shell's generic phases.

[edolstra]

This is expected behaviour. You can't create valid paths with nix-shell because there is no guarantee whatsoever that an interactive build via nix-shell produces the same result as the actual build.

(However, if you really want to, there is the undocumented command nix-store --register-validity to mark a path as valid.)

[jraygauthier]

Ah perfect. This is exactly the sub-command I was looking for yesterday. Thanks for the very quick answer.

I understand indeed the concept that it may have been explicitly designed that way. However, I was
under the impression as you confirmed that there was a way to explicitly bypass this security:
otherwise, why create a link to the store at all. Happy to know this is possible.

Just for my own understanding and maybe that of others:

Could there also be others undocumented feature with nix-build to allow incremental builds?

1. Using nix-build, I see you can specify -K to preserve the temporary directory in cases of
   failure but then, you actually loose it in cases of success. I was thinking about something like the
   explicit specification of a persistent location for the working directory + an explicit way to specify the
   phases to use after initial build (could be even more specific with a --incremental option).
2. Are there easy ways (specific or unspecific to the the haskell / cabal workflow) using myEnvFun
   to bridge the gap between developing / testing an observed module in isolation and its installation (see original comment for specific meaning) so that its complete interaction with other modules in the
   env is also testable?

[peti]

I suppose this issue can be closed ... please re-open otherwise.

[i5hi]

had the same error. sudo reboot fixed it.