[Nix-dev] Nix 1.2 released

[Marc Weber]

Thank you all for those improvements
>   * Nix has a new binary substituter mechanism: the binary cache. A binary
>     cache contains pre-built binaries of Nix packages. Whenever Nix wants to
>     build a missing Nix store path, it will check a set of binary caches to see
>     if any of them has a pre-built binary of that path. The configuration
>     setting binary-caches contains a list of URLs of binary caches. For
>     instance, doing
> 
>     $ nix-env -i thunderbird --option binary-caches http://nixos.org/binary-cache
Thus are non root users allowed to choose binary caches? Thereby they
could download compromised binaries having the same store paths than the
system might have ..

>     outputs = [ "lib" "headers" "doc" ];
>     This will cause Nix to pass the intended store path of each output to the
>     builder through the environment variables lib, headers and doc. Other

Which is kind of bad because LIB may be used by scripts - its too short.
I expect collisions. what about using out_lib out_headers
out_doc ?

I mean we want short names like .lib for installation, inspection and
whatnot. I just don't think its a good idea to use those short names for
env vars (especially the lib case).

>   * Dashes are now valid as part of identifiers and attribute names.
:)
How to quote them using nix-env -A ?

>   * The new operation nix-store --repair-path allows corrupted or missing store
>     paths to be repaired by redownloading them. nix-store --verify
>     --check-contents --repair will scan and repair all paths in the Nix store.
>     Similarly, nix-env, nix-build, nix-instantiate and nix-store --realise have
>     a --repair flag to detect and fix bad paths by rebuilding or redownloading
>     them.
Can you be little bit more verbose about which risks you run doing so?
Eg is it "atomic" or do you run the risk having a broken system for a
short period of time?

>     Nix will automatically make /nix/store writable as needed (using a private
>     mount namespace) to allow modifications.
This requires chroot builds, correct?

>   * Store optimisation (replacing identical files in the store with hard links)
>     can now be done automatically every time a path is added to the store. This
>     is enabled by setting the configuration option auto-optimise-store to true
>     (disabled by default).
Any experience about performance? Why is it disabled by default?
I mean will this require reading all of /nix/store/* to find duplicate
files even if all you do is installing a small tool into your path?

>   * The command nix-copy-closure has a new flag --use-substitutes (-s) to
>     download missing paths on the target machine using the substitute
>     mechanism.
cool ! I was happy reading about it.
 
>   * Chroot builds are now supported on systemd machines.

Have you also had time to think about supporting git hashes in addition
to sha256 values? For many dynamic things like getting packages from
rubyforge, puypi etc you know the git commit hash, but not a sha256 or
md5 value. Verifying such a store path would require running a git
command and keeping the .git directory (so maybe you don't even need to
checkout the files)

And no, its not always an option to prefetch everything you may not need
at all.

Note that I don't ask you for implementing - just for sharing your
thougts on the topic - and if - how you'd implement it.

Marc Weber