[Nix-dev] Using nix-shell in messy trees with symlinks and binary files

[Colin Putney]

On Mon, Feb 15, 2016 at 11:39 PM, Kosyrev Serge <skosyrev at ptsecurity.com>
wrote:

> Good day, folks!
>
> What I'm seeing is a rather disturbingly odd, context-depenent behavior of
> nix-shell:
>
> ,----
> | [deepfire at andromedae:~/src/foo]$ nix-shell default.nix
> | warning: dumping very large path (> 256 MiB); this may run out of memory
> | error: file ‘/home/deepfire/src/foo/generated/rootfs/chroot/dev/fuse’
> has an unsupported type
> | (use ‘--show-trace’ to show detailed location information)
> |
> | [deepfire at andromedae:~/src/foo]$ mv default.nix scripts/
> |
> | [deepfire at andromedae:~/src/foo]$ nix-shell scripts/default.nix
> |
> | [nix-shell:~/src/foo]$
> `----
>
> The directory structure, indeed, has some oddities -- device files,
> symlink loops, this kind of stuff.
>
> Consideration that nix-shell tries to compute some.. hash.. out of it all,
> sends shivers down my spine.  That's a lot of stuff to hash through.
>
> If this theory is, indeed, correct, what would be the way to make
> nix-shell disregard certain paths from the equation?
>

The problem here is that nix is trying to copy a large part of your
filesystem into the nix store. It does that when nix expressions refer to
files that aren't in the nix store. A derivation can only depend on other
derivations, so if you include data that isn't in the store, there's an
implicit derivation created that contains it. What you need to do is find
these implicit references and make them explicit - eg using the filterSrc
builtin. That will both speed up evaluation, because you'll be copying much
less data, and enable you to avoid these errors related to unsupported file
types.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160218/16aa9a3c/attachment.html