I also have the feeling that the tutorials start with the details, instead of starting with an overview so you can understand what is what.
This is guide us already very helpful and I think one should read it before the official tutorial. Thank you!
When you are trying to be as different from everything else as wide-reachingly as Nix is, it seems to work better to build an understanding up rather than down. This seems to frustrate a lot of people because it does not give much payoff for the first few hours of learning (and that's a lot to invest to even understand what something is). The truth is that Nix is really really complicated (expect a year-long learning curve to truly "get" everything), but it's also really hard to take the more-standard approaches to building packages and managing machines seriously once all the pieces finally do all connect. Unfortunately, it kind of makes one feel like being an early adopter of git in a world where no one else uses version control. It's like, "Yes, this is way better, but I'm not going to be able to get anyone else to use it."
This is a fantastic analogy.
I think it's also worth noting that git's UX is notoriously bad for newcomers. These days I'm pretty comfortable with digging myself out of any hole I might mistakenly get into with git. But when I first started using it, all I could do was trivial uses of add/commit/push/pull/merge.
I think the equivalent of "trivial uses of the basics" in Nix would be a "for this use case: just do it this way. You'll understand why later".
I think Guix might be the answer as a more approachable implementation of the Nix ideas, using Scheme for its config language. I haven't spent much time with it but I got going a lot quicker initially compared to Nix.
Out of curiosity, did you tried Guix before trying Nix or vice versa?
When looking at Guix myself, all I see is that the derivations are just wrapped in parentheses otherwise they do look similar. So I'm wondering if scheme actually brings anything here, especially for someone not familiar with a functional language.
IMO Nix language isn't actually that hard, I believe the most complexity comes from nixpkgs and still not adequate documentation of it, so one needs to study its source code.
It’s too bad that guix uses old style mailing lists for development though. I just can’t be bothered setting up myself for that mode of contribution, so I’ll continue to use NixOS for the indefinite future.
I think especially because it's so different you should start with broad concepts and examples, so that the learner can create a broad mental model where they can fill in the details. Otherwise if you hit them with a barrage of details they won't remember any of them later on, because they don't fit anywhere into a broader concept and are disorganized.
Give a few examples that do something useful, show what they're doing differently than other package managers, then break down these examples into the details.
Yes. Reading the official docs, or Nix pills, gives exactly this impression.
I've read some good documentation away from the official docs on how to start using the package manager.
But understanding the overview of how to package things yourself is all wood and no trees.
There's so many moving parts in nix that knowing how they all interact, and which ones are important for your task at hand, is a headache.
function nix-local-build
nix-build --no-out-link \
-E '(import <nixpkgs> {}).callPackage ./'$argv[1]' {}'
end
nix-local-build some.nix
nix-env -i [store-path-from-build]
Question 2 - How to include such a derivation into configuration.nix?
Question 2: including such a derivation is easy with overlays or with the method above.
drv = import ./path-to-derivation.nix;
package = pkgs.callPackage drv {};
After you write a derivation that you can build, you need to create a module [1]. The module defines configuration options, then takes the donation and does other things such as creating service users (if needed), services and configurations.
Then you simply import it and use it.
Regarding question 1 what was suggested by others is what is the current way of doing it, but I will recommend to go through Nix Pills[2]. The author starts with making a simple derivation and then starts introducing conventions. The conventions make things more complex, but they make things more flexible. I can't wait for Flakes[3], they will standardize a lot of this, removing extra cruft and allowing things to be more composable.
[1] https://nixos.org/nixos/manual/index.html#sec-writing-module...
I've even read most Nix Pills posts, but didn't like them much. Too many details about things that I didn't understand at the time of reading, so the why got lost. In Nix you get a lot of details, what is missing is often the why and how. For example I wanted to have a CLI command available with a binary build, finding out how to add the CLI tool to the package through wrapProgram in postInstall wasn't fun. Overall Nix is awesome, but here and there it is hell of a lot frustrating. After reading so many hours I should not have to ask how to install a custom package the right way.
I have overlays in ~/.config/nixpkgs/overlays.nix (though you do this various ways)
My overlay file has the form:
let my-packages-overlay = self: super: { foo = super.callPackage ./path/to/package.nix {} } in [ my-packages-overlay ]
Then you can just nix-env -iA your-package.
This is what always gets me stuck. It seems like lots of tutorials assume you're installing packages by hand still. For me, the whole reason I'm using nix is so that I can use the declarative package management.
I get having local dev dependencies on a per-project basis and running a nix shell to make those dependencies available in your development environment.
But it's just confusing to me how many tutorials suggest running nix-env -i to imperatively install a package. Why would I do that instead of taking advantage of the joys of declarative package management?
So in many cases you are told to use nix-env, because the person just answered how to write a derivation and didn't go further than that.
I think flakes (still work in progress), will help here, because it defines a standard that supposed to do all of that in one file that is easily composable.