[Nix-dev] 5 somewhat related questions

Thu Jun 22 22:30:43 CEST 2017

Klaas,

First, welcome to Nix! I hope you'll enjoy it as much as I've been.

Second, your questions seem like prime additions to
https://github.com/nixos-users/wiki/wiki/Documentation-Gaps which I hope
will inform future version of the Nix manuals.

I'll do my best to share my understanding vis-a-vis your questions, but
they highlight weaknesses in my own understanding as well.

On Thu, Jun 22, 2017 at 11:41 AM Klaas van Schelven <klaas at vanschelven.com>
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)
>
> The products of runinng nix-env --install live in profiles (as, in fact,
do nixos-rebuilds) - there's a diagram here
http://nixos.org/nix/manual/#sec-profiles that I found useful for
understanding how profiles work. Specificially, every user has their own
"~/.nix-profiles" directory, and the system as a whole has a collection of
profiles. System and user profiles are blended, using Unix pathing
mechanisms. If, for example, you check your PATH, you'll see references to
/home/username/.nix-profile/bin and /run/current-system/sw/bin.

nix-env --install is incredibly convenient to quickly install a program you
need in the moment. Even better is when the "not installed" warning are
working properly (which relies on your channel etc) and you can copy and
paste a nix-env command to get the tool you need _right then_, and take a
little maintenance time later to "purify" things.

I've found it useful from time to time to do a nix-env -q, and migrate the
list of installed packages to nix configuration.nix, and then delete my
local installs along the way. I sort of wish that there were a mechanical
way to do this, but it'd involve editing configuration.nix automatically
and triggering nixos-rebuild, which I'm loath to undertake myself.

Admittedly, there is some potential for confusion involved when you've
nix-env'd a package, since you e.g. won't see it update when nixos-build is
run. Also beware interactions like dmenu or neovim installed in one place
and programs or plugins installed in another.

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?).
>

 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.

>
> 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?
>

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.

> 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"?
>

It is possible to use ~/.config/nixpkgs/config.nix for this. There used  to
be a wiki article about using overrides to create an "all-packages"
derivation that would work like a personal packages: []. I don't think (but
might be wrong) that modules can be used in this context, so replacing
personal dotfiles is trickier. My impression is that this is an approach
that people take as they get very comfortable with nix, and as a result
everyone goes their own way.

> 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
>
> I'm keen to see someone better appraised's response to this.

Judson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170622/8c6f2ecc/attachment-0001.html>