Nix will gladly download anything it needs from binary caches, if available. It is also configured to know about official binary cache by default. You can add more binary caches.
If something is not available locally or in the caches, Nix will fall back to building the package. This usually happens if you are overriding something for a package, say you include an extra compilation flag (emacs >:( ), because then the derivation's hash is different, and the binary cache knows no such thing. Or if what you are building is so old that it was removed from the caches to make space for the fresh stuff.
So, yes, pre-built backages are provided and are the default. However, the fallback exists too.
They have pre built packages for x86_64, so with default options you shouldn't have to compile most common packages. Of course if you change a setting which would produce a different output than the cache, it will trigger compilation of that package. You (or your organization) can also add your own "substituters" (nix terminology for binary cache). This helps if you want to automate builds using your own custom compile options and can be deployed to many machines.
I read a blog post where they talked about using nix develop to set up a dev environment and they said it would build all the required tools from source which is why I was confused.
nix develop just drops you into a shell which has all your environment variables set correctly and packages available in your $PATH. And for that, it will use the same functionality to either re-use a package you already downloaded, or check if it's available as a binary from a binary cache, or in the last case it will bulid from source.
I'm not doing much hobby development these days, but I think nix develop can be used in tandem with direnv (https://direnv.net/) to get you to a development shell automatically, just by navigating to the directory in your terminal.
I have a favour to ask of you. Please feel free to ignore if you don't have the bandwidth. I won't mind at all.
I was thinking of putting NixOS on my SBC so that I could version control its configuration and also learn NixOS. Due to the weird nature of SBCs it's not guaranteed every Linux distribution will work on them.
The favour I mentioned before is that I have two questions about it:
Is this repository still relevant despite having no commits in over three years?
What does this repository exactly do? I cannot in good conscience ask you to go in details but some high level explanation would be appreciated. I tried reading the .nix files but they made no sense to me.
Hi! Sorry that it's probably beyond me, the smallest computer I have installed Nixos on is a raspberry pi. It was pretty easy because I just used instructions online from someone who already did it. I'm on a trip without my laptop at the moment so I can't try building from this repo.
But the process for building for rpi is that there's a way to define a configuration.nix that gets used to generate an SD card image. So that looks like what the repository you used is doing. You run nix build to generate the image (goes into a 'result' directory) and then you can flash that to an SD card (for example using dd).
Also, I saw this fork of the repo you linked, looks like someone added a little bit of instructions how to cross-compile (so you don't need to build from an aarch64 machine) and also updated a path which changed between nixos versions.
If this repo works for you, I'd recommend using a remote deployment tool like deploy-rs. I use it for my raspberry pi. It means I can build (cross-compile) packages for the rpi on my desktop computer, and then copy the packages to the rpi via ssh and activate the generation.
One more comment! You might see some differences in nix commands being used across different blogs. This is because they are slowly migrating to a new command line API and away from the old API. Generally, if it's using the new API (experimental/unstable), then it just uses the nix command. The older stable API generally has dashes, like nix-build, nix-shell, etc. But there's usually some matching command in both APIs.