Afterwards, we call the function with the empty set. We saw this already in the fifth pill. To reiterate: import <nixpkgs> {} is calling two functions, not one. Reading it as (import <nixpkgs>) {} makes this clearer.
But I am a big dumb stupid-face.
What I canāt understand is what {} is doing here??? If I had to break this downā¦
import <nixpkgs> evaluates <nixpkgs>/default.nix, which returns a map expression
with (import <nixpkgs>); ... essentially ādestructuresā the map so itās members are available as vars in the following expression
No, it does not. It evaluates to a function, which then gets passed {} as its argument.
It is more clear when you see things like import <nixpkgs> { config.allowUnfree = false; }.
IIRC the REPL does indeed surpress build output. I know for sure for 2.4, and assume it is the same in 2.3.
I have to say though, that the pills are not suitable for beginners, and actually not even necessary. It explains the low level way to create packages and there are much higher abstractions available within nixpkgs which are nicer to work with, like mkDerivation. I look at them more or less regularly, read half of the first pill that deals with packaging and then leave it alone. Still I wrote my packages and am maintaining them in my flake and nixpkgs. Thats fine. There are abstractions in nixpkgs (like mkDerivation) that allow you to not have to care for that low level stuff and give you a nice āphasedā interface similar to one might be used to it from PKGBUILD or emerge build descriptions.
There are abstractions in nixpkgs (like mkDerivation) that allow you to not have to care for that low level stuff and give you a nice āphasedā interface similar to one might be used to it from PKGBUILD or emerge build descriptions.
I donāt have any background writing Linux build packages and tbh they all look like mysterious incantations to me.
Buuuut I like NixOS and occasionally need to build things from GitHub which only have debian or arch instructions soā¦
There is a strong chance this is an insurmountable problem for me b/c Iām not really interested in learning nix. Itās a hoop I have to jump through to do this thing I need every few months.
I have seen some crazy workarounds in nix build expressions and donāt have the C experience or requisite Linux experience to have engineered them.
So I will likely give up at the first novel hurtle.
If you do not want to learn nix, then why read the pills? Those teach fundamental low level nix.
Though I have to be honest, you can not use nixos without at least learning nix the language, as this is what you need to use to configure your system.
And since you got already this far with the syntax, its not far away to learn basics of mkDerivation.
At the end, it is just a function call that you pass a couple of arguments, which describe the build.
Those strings represent shell scripts which run in an isolated environment and you have basically 3 important phases:
configurePhase runs scripts that generate configuration or headerfiles needed for the build, but not provided by the source, as they are target specific. Ie it runs ./configure
buildPhase runs scripts that actually build the project as required, eg. make.
installPhase runs scripts that copy the previously built artifacts to their location in the store, eg. make install PREFIX=$out
Not all programs are easy to package, especially those that have strict assumptions about FHS or hardcode pathes. For those you often need to also use patchPhase or fixupPhase.
At the end, you could in theory as well just lump together all the phases into a single one and do all work, from configuration to install in that single phase, though the classic separation makes it easier to debug the build script.
If you really are in doubt, and have no clue how to proceed, ask someone if they could help you packaging something or if they package it for you.
Though I have to be honest, you can not use nixos without at least learning nix the language, as this is what you need to use to configure your system.
I have been āgetting byā on my personal desktop and laptop by using the wiki and other community resources. And most of the time thatās unnecessary because the package list is straightforward and Nix has a deep well of packages to choose from.
This is the second time reading the nix pills b/c I didnāt āget itā the first time.
I could level a minor criticism about nix at this point but it wouldnāt negate the fact that Iām just not very smart.
I feel compelled to respond to this. I believe most people who encounter Nix and try to get into it have this feeling (myself included). I trust that I am pretty smart (I went through a lot of school, and I make a living with my brain, after all) and even so NixOS and Nix has been a rocky, steep, and difficult climb, sometimes with ice and freezing rain falling (overlays) and sometimes with the sun shining brightly (flakes). I am persisting only because I know thereās an amazing taco stand at the top of the mountain.
So many people who try out Nix do indeed find it difficult, perhaps believing they are not smart enough to get it, but the trick is that if everyone feels that way, then the difficulty must lie with Nix. I say this out of love and wanting desperately for things to get easier. I believe that some concerted messaging around the right way to do things, to improve the tooling (which is ongoing as we speak), improve error messages, and figure out how to curate a collection of high-quality tutorials, cookbooks, and documentation would go a very long way towards easing the new user experience. I know some of this exists already, but the very fact that people keep going back to the Pills series (which is both extremely high quality information, and extremely difficult to grok) means that itās not enough yet. Unfortunately, Iām not sure how to help things get better myself, but as I learn things, perhaps I will try to write them down and share those writings.
Nix/NixOS is probably the best Linux distro Iāve ever used, but I really do wish I were ābetter at itā.
Thereās https://nix.dev/ which is going in the right direction.
I think nix needs basically something like an extended nix.dev, a one-stop shop for curated, goal-oriented tutorials that cover just enough to understand everything required to achieve some specific goal (i.e. āuse flakesā, āoverride a package versionā, āinstall a non-nix packaged applicationā), without too much background about how it all works (but links to provide easy looks into documentation and other information sources).
Thatāll give a much easier index into the terse inner workings, and with enough reading of something like the above the nix pills lose their complexity.
Iād like to write something like that, but donāt know where to begin, especially since itād have to be something semi-official that people will easily run into shortly after starting to experiment with nix. And also I donāt know if I actually have the time and writing skills
Basically, I think the āintermediateā documentation for nix is missing. We have great basic beginner docs (the install guide, help menus, error messages, wiki pages, options search and some other things), and lots of heavy docs on nixpkgs and nix (ranging from the nixpkgs documentation all the way to the original nix paper), but not much for slightly more complex use cases that arenāt writing a new distro.
Itās a side effect of the main user being NixOS, and most people huddling around it to make nix work properly. I do think thereās a bit of an ongoing shift, with the growing userbase and the existence of flakes, that may change this though
One small thing that is changing is the new documentation theme for the official docs. Nix 2.4 came with a searchable readthedocsey thing that is much more navigable than the old HTML dump, which has IMO already significantly improved matters. There are upstream issues for doing the same for the nixpkgs and nixos docs.
Nix language is pure functional which implies a very different point of view and mindset to address problems comparatively to imperative one. By example overlay stuff is lot more simple to appreciate when you grasp the concept of fixed point (no so difficult in fine). My practical advice is to enhance your confidence in (Pure) functional language (recursion, list manipulation, higher-order functions, lazy evaluation, fixed pointā¦)
@augu5te That doesnāt ring true to me. Maybe thatās the case for a lot of people, but I have a lengthy background w/ Clojure. All of those concepts are āold hatā for me.
Seconded. The problem (at least for me) is emphatically not the FP nature of Nix, which will come naturally to most CS folk. While the fixed point formulation of the package set is indeed a difficult concept compared to what you find in other distros, it takes a bit of explanation and then a demonstration by example to show how it works and then most people will succeed with it most of the time.
The problem is that the gap between the descriptions of things at a more theoretical level (as presented in much of the existing docs) and a concretely usable instantiation of those ideas is too often far too large to cross easily, even for smart people who understand the ideas. Iāve closed the gap on occasion by adapting examples I find on, e.g., discourse, or asking people in the IRC channel, or attending the Friday office hours sessions, and then immediately saving what works in a Git repository so I can study it later, and absorb the practical patterns.
Thereās a specific lack of examples and explanations for how a system running Nix or NixOS comes together in a specific way. Thatās something Iād like to fix.
I am just now realizing that Iām just saying what @TLATER said upthread, but not as well. Consider all this another āsecondedā for that post. And thanks for reminding me about nix.devāneed to spend some time reading what all is there, and thinking about what still might be missing.
Honestly, I think there is a critical mass of people who are on the verge of becoming hyperproductive with Nix/NixOS, if only we could solve that āmiddle documentationā problem. If there isnāt common knowledge of the existence of this group, then we canāt solve that problem. So please keep speaking up and letās see what we can do!
