[Nix-dev] 5 somewhat related questions

[David Izquierdo]

I'll try to answer what I think I know...


On 22/06/17 20:40, Klaas van Schelven wrote:
> Hello Nixians,
>
> I've installed NixOs a number of days ago. So far I really like it!
>
> I've read the documentation I could find, but I'm left with a number of
> questions; not so much "how to do X" but rather of a slightly more
> philosphofical (or cultural, a.k.a. "best practices") nature. I hope
> someone can enlighten me on the "Nix Way".
>
> 1. In NixOs /etc/nixos/configuration.nix is the single configuration file
> that determines the state of the system as a whole. How does this file
> relate to the existence of the nix-env command, either executed as root or
> by a single non-privileged user? In particular, I would assume that any
> nix-env is undone by the time the system is rebuilt from the configuration
> file. Assuming this is the case: should the usage of nix-env not be
> actively discouraged in NixOs? (perhaps it is, and I simply did not find
> the reference)
They're mostly independent, but AFAIK nix-env binaries have priority 
over conf.nix. Nothing gets undone, since whatever you install to your 
user profile stays in the nix store (because your user profile is a gc 
root). For me, the use of n-e is because it's faster to test or use 
oneshot software installing it imperatively than adding-then-removing to 
conf.nix. I guess `nix-shell -p` would be more "correct", but it's a 
matter of not forgetting you've used it.
>
> 2. (Context: Assuming for a moment there _is_ in fact a use-case for
> nix-env; e.g. the scenario where you're not running NixOs, but are using
> Nix on top of another distribution). nix-env uses an "imperative style" of
> manipulating your environment, i.e. using a sequence of commands in a
> particular order. I understand that after each succesful manipulation the
> _resulting_ environment becomes available as a separate generation. As far
> as I understand there's even a "half-product", the so called "derivation"
> that is available per generation, although I did not study those yet. My
> question is, however, whether the original commands that led to these
> constructions can somehow be retrieved. The reason for this question is the
> observation that the sequence of nix-env (and potentially other similar)
> commands can be seen as a transactional log that could simply be replayed
> to reconstruct the resulting generations (assuming that the commands fully
> express the information needed to construct the associated environments;
> this assumption might not actually hold in practice. Question 2b: does the
> assumption hold?).
>
> 3. In the scenario where I use the single configuration file
> /etc/nixos/configuration.nix but I'm also subscribed to a channel, the
> state of this channel may influence the outcome of nixos-rebuild (This is
> by design, it allows us to stay up to date with e.g. security updates). The
> consecutive states of the channel, as seen by my system when rebuilding,
> are valuable pieces of information in their own right when I want to debug
> a problem. Take the following example:
>
> t=0, my system is good.
> t=1, I want to install some extra package, I modify configuration.nix, and
> run nixos-rebuild
> t=2, system broken.
>
> I understand that I always have the ability to roll back the system _as a
> whole_, even using Grub if needed. This is awesome of course. The question
> is: do I also have the ability to debug the parts that lead to that whole?
> In particular: the precise state of the channel[s] on each rebuild? And
> preferably also: the state of /etc/nixos/configuration.nix on each build?

I think you want `nix-channel --rollback`, and 
`system.copySystemConfiguration = true` (for c.nix). Note however that 
at some point it will probably be in your best interest to modularise 
your c.nix into several files, and that option only copies c.nix, not 
any imports. You can check this message for a fairly elegant method to 
have your /etc/nixos tree be a part of each generation.

https://mailman.science.uu.nl/pipermail/nix-dev/2017-April/023403.html
>
> 4. Is a "single declarative file per user" (e.g. for dotfiles, but
> potentially also to make it possible to declare which user-specific
> packages are installed) available? I understand there some options exist,
> but how do they relate? Is there convergence on a "one way to do it"?
>
> 5. In the commit linked below, the nix file for VTE 2.91 adds the following
> 2 propagatedBuildInputs: pcre2 & gnutls. As far as I understand this might
> be not good practice. The reason I've added them is because pkg-config,
> when run in the build context of xfce.terminal, cannot otherwise find the
> package vte-2.91 because of a dependency error. Ignoring for a moment the
> rationale of the commit itself (I've been convinced that adding this
> particular version of xfce4-terminal to the repo by itself is not a good
> idea) can someone tell me what the proper way to handle this particular
> situation would be?
>
> https://github.com/NixOS/nixpkgs/pull/26742/commits/5e566d3c8a078f6cd6304e7cf0b409a8260ee71c#diff-52903c4477fc53869e7e92148494cbe5R17
>
> Hope this isn't too overwhelming a wall of text - feel free to answer only
> partly if you see fit.
>
> Thanks in advance,
> Klaas
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev