[Nix-dev] 5 somewhat related questions

Klaas van Schelven klaas at vanschelven.com
Fri Jun 23 12:42:29 CEST 2017


Judson,

Thanks for your answers!
I've documented where your answers led me below for myself and others below.


> 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.
>
>
Maybe... the biggest missing "thing" in the documentation that I've
encountered so far is not any particular gap, but rather the organization
of the material. I have not yet reached the level where I can reorganize
all of the documentation myself though, nor do I have the time for it :-)


> I'll do my best to share my understanding vis-a-vis your questions, but
> they highlight weaknesses in my own understanding as well.
>
>
> [..]
>> 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.
>

Yes, the diagram is very useful!
One thing that's missing from the diagram (and my understanding until an
hour ago) is that the PATH value is in practice not a single value, but
rather a list (as is usual for paths, but I didn't necessarily assume that
Nix would do the usual thing). This gives rise to the "blending" that you
mention above, so that a non-privileged user has access to their own env,
the root's env, and the "system" env (AFAIU, the env that's generated from
the configuration.nix).

To answer my own question: root's nix-env and the configuration.nix are
independent from each other and their blended results will be available to
all users. This means that running nixos-rebuild after some imperative
style nix-env commands will in fact *not *undo those nix-env commands. Your
remark that ~


>
> 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.
>
>
This is a good tip on an actually practical workflow!



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



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

Do you have a pointer to this discussion? I cannot find it using the
keywords you mentioned above.


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

The 2 starting points into this (1 of them linked by Nawal) are:

https://github.com/kamilchm/.nixpkgs/
https://github.com/NixOS/nixpkgs/issues/1750


Thanks very much,
Klaas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170623/639f371f/attachment-0001.html>


More information about the nix-dev mailing list