[Nix-dev] 5 somewhat related questions

[Linus Heckemann]

Hi Klaas,

>> That intuition holds modulo your Q3 - replaying a sequence of
>> nix-env commands would only reproduce the same generations if a)
>> the states of all channels involved were retained (i.e. you'd need
>> to know which nixpkgs-stable you installed from with each command)
>> and b) all the builds were reproduce-able or cached. Nix assumes
>> reproduce-able builds, and so retains the outcomes of building
>> derivations based on a digest of the derivation itself - but if you
>> replayed the same nix-env commands from scratch, you might get
>> (trivially) different outcomes.
>
> Out of those 2 remarks "a" is the big one, especially if the channel 
> you've subscribed to is in fact not the stable one. As far as I
> understand now, there is no solution for this (yet). Good to know
> though.

You can, instead of using nixpkgs/config.nix, write an expression for
your user environment somewhat like this (say software.nix):

let pkgs = import <nixpkgs> {}; in
{
  inherit (pkgs) vim ripgrep ;
}

You can install this using:

nix-env -f software.nix -i

If you add the -r flag, the result will not depend on the previous
generation of your user environment. The benefit of this approach is
that you can replace pkgs in order to pin specific versions, for instance…

let
  # System nixpkgs used only to fetch pinned nixpkgs
  bootPkgs = import <nixpkgs> {};
  pkgs = import (bootPkgs.fetchFromGitHub {
    owner = "nixos";
    repo = "nixpkgs";
    rev = "d10fe641247e29b72139776cd3163344443b13ba";
    sha256 = "06viplacb5w49yf3rirsn4jdcfssj98f3s1zic0l8raxng7pmdcq";
  }) {};
in {
  inherit (pkgs) vim ripgrep;
};

Which is a bit harder to maintain but should be much less stateful,
depending only on fetchFromGitHub from your current nixpkgs not breaking
compatibility and on github staying up — and importantly, it would allow
reproducing previous generations more easily. You could of course also
factor the fetching out into a separate file which you could import and
have a script to automatically update. I wouldn't be surprised if
someone had already done that somewhere.

In a similar vein of functionality, you could version your user
environment in a git repo with nixpkgs as a submodule and update it
explicitly. This would provide a similar experience and further reduce
the variability.



> The rollbacks will be as-built, so implicitly they capture the state 
> implied by the channels and configuration.nix. However, there's no 
> explicit capture of those - there was discussion relatively recently 
> about capturing configuration.nix into the generation, but it turns 
> out to be a little harder than you'd expect. Likewise, you'd have to 
> somehow capture the state of all the involved channels.
> 
> 
> Do you have a pointer to this discussion? I cannot find it using the 
> keywords you mentioned above.

This was the discussion David Izquierdo linked in his reply:
https://mailman.science.uu.nl/pipermail/nix-dev/2017-April/023403.html

Linus