[_hl_]

> Error messages that tell you absolutely nothing about what went wrong were pretty common.

Maybe I'm holding it wrong, but I almost never get useful error messages from Nix (NixOS and NixOps). Almost every error is deep within some module with no trace to the option I set. Just nix barfing its 300-line eval traceback where my own code doesn't even appear.

[geddawm]

Nix has a debugger now. You can drop into the frames that are causing problems and inspect the state. Miles easier than looking at the trace manually.

[benreesman]

I last flashed my flake.lock in June, so I might be out of date, but my rigs can’t reliably include the line number in my code that led to the duck-typing fiasco deep in the core of someLanguage.withPackages.fuck.WTF.this.

Fix the fucking “—show-trace” thing folks. Seriously.

[VTimofeenko]

Out of all cases when I used --show-trace, I can remember it being useful only once or twice. I gave up and just sprinkled builtins.trace.

IIRC debugger comes with nix 2.9 and nixpkgs for 22.05 still has 2.8.x.

[n8henrie]

I was excited to see the debugger flag to nix build the other day, since I'm really struggling cross-compiling an RPi on BTRFS root sd image.

Of course running with the debugger flag resulted in an unintelligible error message and no debugger.

[rtpg]

Any link to documentation on how to use it? Would be a godsend for me

[baby]

I agree. I'm actually trying a hello-world example from the tweag website, and it complains about "gcc" not existing. I try adding

    buildInputs = [ nixpkgs.gcc ];

but it complains that nixpkgs.gcc does not exist. There's nothing helpful. I remember fixing this issue a month ago, and I have no recollection on how I did it.

[hypersoar]

Are you using flakes? You need to use the legacyPackages output for your system, e.g.

  buildInputs = [ nixpkgs.legacyPackages."x64_64-linux".gcc ];

In practice, it usually looks something like this:

  let
    system = "x86_64-linux";
    pkgs = nixpkgs.legacyPackages.${system};
  in stdenv.mkDerivation {
    ...
    buildInputs = [ pkgs.gcc ];
    ...
  }

[benreesman]

So there is more than one way to skin this cat. ‘nixpkgs’ as handed to you as part of a flakes ‘inputs’ is (jargon alert) partially applied, which is to say you have to put a battery in it. In this instance what you have to pass is ‘system’ because nixpkgs supports many systems (e.g. ‘linux-x86_64’ or ‘darwin-aarach64’). It sort of makes sense that it wouldn’t know what GCC you want without that information.

You can do this up top by hand, e.g. P = inputs.nixpkgs { inherit system; }, but more commonly you would use a library like ‘flake-utils’ or ‘flake-utils-plus’ to issue system configuration for all supported packages to all your packages/derivations/devShells.

[baby]

Ah right, I saw that library but it didn’t have examples and I didn’t manage to use it. Do you know a page that would explain that?

[benreesman]

The ‘flake-utils’ readme is a pretty good jumping off point: https://github.com/numtide/flake-utils

I have this or that nitpick with FL and FLP but overall it’s very solid stuff. FLP is a little more “magical”, and that’s not always the best starting out, but you really can’t go wrong with either.

[Smaug123]

Maybe you got confused (like I did every time until I stopped doing anything non-flakey) about when `nixpkgs` is called `nixpkgs` and when it's called `pkgs`? In the flakes world it's considerably easier because everything is explicitly named, so you take an actual decision about what to call it.

[baby]

Is the convention to call it pkgs when you instantiate it with a system?

[cmm]

yes. other possible arguments are overlays and package selection modifiers (like whether to include non-free stuff or stuff that is marked as broken).

[kaba0]

I don’t know what is the specific file you are working on, but shouldn’t it be pkgs.gcc?

[SuperSandro2000]

That's strange. GCC is part of the stdenv on Linux and though always available.

To correct your coffee snippet: nativeBuildInputs = [ pkgs.gcc ];

[baby]

I’m on mac, I managed to fix it with https://mimoo.github.io/nixbyexample/flakes-packaging.html

[baby]

And now I’m trying to understand how devshells work in flakes and there’s pretty no doc

[benreesman]

So a dev shell as consumed by a flake is typically just a derivation. And typically the most important thing in that derivation is ‘buildInputs’, which is just a list of ‘pkgs.thingIWant’. It’s not uncommon to hook other “phases” of the derivation, which are (oversimplified) just little shell scripts that run in some order (‘configurePhase’ before ‘installPhase’) and typically expressed using the nifty “” syntax. For example if Nix is like stuffing paths into a Makefile that you want to use in your dev shell, you might put that in installPhase. Protip: a Nix “package” (derivation) evaluated in a string context (foo = “${pkgs.gcc}”;) gives you a path to where the thing lives in /nix/store.

[Smaug123]

Ask your questions on discourse.nixos.org please - the documentation situation in Nix-land is generally exactly as you have noted, which means centralised question-asking in well-known locations is much much more helpful for Those Who Come After.

[benreesman]

I say this with the utmost respect for those who work hard to answer questions on discourse, but I have found it singularly unhelpful.

I strongly encourage the Nix community to embrace a mainstream Q&A platform like StackOverflow or GitHub Issues.

Nix is “weird” enough for beginners already, the kind of janky interface and uneven moderation/quality on discourse is IMHO self-defeating for Nix.

[baby]

Agree. I feel the same way about OCaml, and I have forced myself to ask every questions I have on SO to build the list of answers there. Yet, people tend to answer on SO with “you should ask on the OCaml discourse”…

[pxc]

Aside: I love the Discourse UI. It feels easy and thoroughly modern to me. What's janky about it, in your opinion?

[baby]

I also do not like it for different reasons (one of them is that they hijack ctrl+F)