add system.copySystemNixpkgs nixos option

[bennofs]

This option copies the version of nixpkgs that was used to build the system to
the system path. This is useful for two reasons:

• it allows for reproducing a given system state
• you can easily keep the nixpkgs version that your user uses and that the
  system uses in sync

---

If no one disagrees, I will merge this in 2 weeks (2017-25-07).

[FRidh]

I like the idea but if it doesn't copy files it references, then that is a serious limitation which wouldn't be obvious for the unaware user either.

[bennofs]

@FRidh: hmm, is it common to have symlinks in your nixpkgs? Most people just build from a nixpkgs checkout with a few additional commits on top, I'd assume. And the nixpkgs repo currently contains not a single symlink.

[FRidh]

And the nixpkgs repo currently contains not a single symlink.

hardware-configuration.nix?

And what about keys and such? I think the majority of cases will have references to other files.

[bennofs]

@FRidh this is about copying the nixpkgs, not the configuration. So if you use nixos-rebuild switch -I nixpkgs=/custom/nixpkgs, it'll copy /custom/nixpkgs. One useful thing that this allows you to do is to make the system nixpkgs stick: whenever you update your system to a new nixpkgs, you can set NIX_PATH in a way that all future nix commands will use the same nixpkgs version. For copying the configuration, there is already copySystemConfiguration which only copies the configuration.nix. That could be improved, but is unrelated to this PR. Was the documentation I added for the option misleading, and if so, any idea how it could be improved?

[FRidh]

Was the documentation I added for the option misleading, and if so, any idea how it could be improved?

No, I just didn't read it properly. Ignore my earlier comments!

[fpletz]

Great idea!

[grahamc]

I love this! What if this also automatically added to NIX_PATH?

[bennofs]

@grahamc IMO, adding to NIX_PATH should be a separate option (that would also enable this option of course). Two reasons for this:

• You may want to use this option only for backup purposes. Then, you don't want NIX_PATH to be modified
• Adding to NIX_PATH makes nix-env and nix-build inconsistent: nix-env uses ~/.nix-defexpr and not NIX_PATH

[edolstra]

I don't think we should do this. It has the same problem as system.copySystemConfiguration, namely, it's incomplete - it doesn't necessarily capture all Nix inputs, so it doesn't ensure reproducibility. And worse than system.copySystemConfiguration, it's rather expensive (and terms of I/O and disk space) because of the full Nixpkgs copy. Every nixos-rebuild needs to read the entire Nixpkgs tree.

Also, it doesn't provide a straightforward way to revert to or modify the snapshotted configuration. You would have to manually copy /run/current-system/nixpkgs, make it writable etc. And since .git is discarded, you can't easily figure out what revision this copy is.

My ideal solution would be to have nixos-rebuild use Nix's restricted evaluation mode to ensure that all Nix inputs are known and recorded. I.e.:

• For each Git tree in $NIX_PATH, verify that it's clean (has no uncommitted changes), and record the commit hash.
• For each channel in $NIX_PATH, record the store path or upstream Git commit hash.
• Evaluate/build <nixpkgs/nixos> -A system in restricted eval mode. So the evaluation will fail if it tries to access any unrecorded file.
• Store the recorded info about the inputs in some file (e.g. /run/current-system/inputs.json). Another possibility would be to automatically generate/update a small Git repo (e.g. in /etc/nixos/system-configuration) that uses Git submodules to point to the input repos. This way, the commit hash of the top-level repo unambiguously identifies the configuration, and you can easily clone an entire configuration.
• Provide some command to restore the inputs to a recorded configuration (e.g. do git checkout <hash> in every Git input).

[bennofs]

Thanks for the detailed response!

It has the same problem as system.copySystemConfiguration, namely, it's incomplete - it doesn't necessarily capture all Nix inputs, so it doesn't ensure reproducibility.

Yes, this is right. But is it actually common to have nix inputs outside of the nixpkgs repo? I think that for most users, this setting would be fine.

And worse than system.copySystemConfiguration, it's rather expensive (and terms of I/O and disk space) because of the full Nixpkgs copy. Every nixos-rebuild needs to read the entire Nixpkgs tree.

Also right. In my experience, this hasn't been such a big problem, other steps during nixos-rebuild often take much longer (and I have been using this code snippet in my nixpkgs revision since a long time already). Additionally, this is setting defaults to false, so the cost is opt-in.

Also, it doesn't provide a straightforward way to revert to or modify the snapshotted configuration. You would have to manually copy /run/current-system/nixpkgs, make it writable etc. And since .git is discarded, you can't easily figure out what revision this copy is.

I don't understand, why would it be necessary to make it writable? You'd have to find the system profile, but you don't need to copy it since you can just do nixos-rebuild -I nixpkgs=/path/to/old-system/nixpkgs. In some cases, you don't even need to find the old profile manually: you can just activate the old profile (for example, by booting the old system).

My ideal solution would be to have nixos-rebuild use Nix's restricted evaluation mode to ensure that all Nix inputs are known and recorded. I.e.:

But is this actually feasible right now? It sounds like a lot more work, for a benefits in a corner case (perhaps it is more common to have additional inputs in large organizations? I only use NixOS on my laptops at home I've never needed any other input except my configuration + nixpkgs).

Even with restricted eval, it seems like Nix doesn't have proper support for evaluation stages. So you'd probably have to do the restricted eval multiple times to discover all inputs.

And, even if it is feasible, what bad happens if we introduce this optional setting? Are you just saying that there should be a bigger warning that it won't capture everything? Or do you think that if we merge this, there will be less incentive to work on a better solution? Or is it because of backwards compatibility concerns (perhaps we can design this in a forward-compatible way then?)?

I'm happy to remove this option again should a better option arise. Personally, I'm using this right now, and it works well for me. Also, looks like a few others already liked this, so what harm would be caused by introducing this option? If we always wait for the perfect solution, we will never get a solution.

[bennofs]

So can I close this?

[bennofs]

This approach is not accepted, so I am closing this PR.