[Nix-dev] 5 somewhat related questions

[Nawal Husnoo]

This is what I use for config.nix, following the example I got it from
(link below).

# nix-env -i all
# https://github.com/kamilchm/.nixpkgs/blob/master/config.nix

with import <nixpkgs> {};

{
    allowUnfree = true;

    packageOverrides = pkgs_: with pkgs_; {

        all = with pkgs; buildEnv {
            name = "all";
            paths = [

bunch
of
things
I
use
but
didnt
want
to
pollute
configuration
dot
nix
with

   ];
        };
    };
}

On 22 June 2017 at 21:30, Judson Lester <nyarly at gmail.com> wrote:

> 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
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170622/8cae39b4/attachment.html>