9 ms·

About using Nix in my development workflow

119 points by Arubis 4y ago

cglong 4y ago
(2018)
galaxyLogic 4y ago
Does it work on Windows?
- chriswarbo 4y ago
  It works under WSL. I seem to remember some other experiments years ago (maybe cygwin/mingw based?)
- breakds 4y ago
  We use NixOS and Nix extensively in the company. A few developers actually use NixOS on WSL as daily driver, and it was pretty smooth.
- pxc 4y ago
  There's a community port of NixOS to WSL2, complete with systemd support, plus Docker Desktop support and some other goodies: https://github.com/nix-community/NixOS-WSL https://github.com/nix-community/NixOS-WSL Nix also works on other WSL distros, provided they're using WSL2. Nix supports cross-compiling Windows binaries as well. I know some people use it for that. There is no 'native' support— you can't use Nix as an alternative to Winget or Chocolatey on Windows. Right now a lot of important stuff in Nixpkgs depends on a POSIX shell and Unix coreutils implementation for the basic build environment, and that's shared between many operating systems. Trying to fit Windows into that doesn't really make sense, and there's not really any momentum behind the idea of using any particular other runtime environment (could be a scripting language instead of a shell + coreutils) for those basic builders. But it's conceivable that some day, one or more companies using Nix on WSL might see vaiue in taking that extra step and put together a Nix-based package collection for Windows and help get the Nix Windows port out the door. It also seems possible that a motivated Nix developer could take it somewhere on their own, since at least one has a workable PoC IIRC (but they didn't want to create/maintain a separate package collection). For now, it works very well with WSL2 and that's the way to go for Windows users.
Arubis 4y ago
I've _tried_ going down this route a couple times, with mixed success. Thus far the best experience has been with [lorelei](https://github.com/shajra/direnv-nix-lorelei https://github.com/shajra/direnv-nix-lorelei), which does a decent job making Nix and Direnv play nice and being relatively transparent and forgettable once set up. Still feels like I don't know what's going on under Nix's hood, though. That syntax...
- lijogdfljk 4y ago
  Some of that functionality is built into Nix/Flakes now.. i believe. Ie i used to use Lorelei but these days i just use Nix and Flakes with Direnv directly. Not sure even how it works, but it works great. But i use Flakes through my entire setup, so i imagine that's why.
- flurie 4y ago
  nix-direnv[1] is pretty seamless and performant once you have direnv installed and set up. I have a devshell flake template that looks similar to theirs. I had an edge case bug that I was dealing with, and they had a release that fixed it shortly after I reported it. [1] https://github.com/nix-community/nix-direnv#flakes-support https://github.com/nix-community/nix-direnv#flakes-support
lijogdfljk 4y ago
As an aisde, i love Nix, but i hate the lack of types. It's such a chore to figure out what fields are on a value, is the value a func, what are the docs for that func, etc. I have high hopes for Nickel[1] [1]: https://www.tweag.io/blog/2022-03-11-nickel-first-release/ https://www.tweag.io/blog/2022-03-11-nickel-first-release/
- flurie 4y ago
  I know Eelco hasn't been heavily involved in Nickel, but I have to wonder what his departure from Tweag[1] means for it. A lot of bleeding-edge Nix adherents are starting to adopt CUE[2][3]. [1] https://discourse.nixos.org/t/tweag-nix-dev-update-33/20048 https://discourse.nixos.org/t/tweag-nix-dev-update-33/20048 [2] https://cuelang.org/ https://cuelang.org/ [3] https://github.com/input-output-hk/bitte https://github.com/input-output-hk/bitte
  - Cedricgc 4y ago
    Interested in hearing more about CUE+Nix Considering the tight integration between Nix language v. Nixpkgs v. Nix program I mostly see CUE usable to generate data files but would eventually need to be consumed in a .nix config at some point
    - flurie 4y ago
      You're basically right. I'm not 100% sold on this idea, but I think it's a possibility. Most of what I'm seeing right now is CUE facing outward, e.g., to generate typed things from within nix. This[1] is a good example of that. Given how flexible CUE is, and given how similar nix is to HCL, I think it's possible to have CUE emit nix and provide some basic typing that way. [1] https://github.com/jmgilman/nix-cue https://github.com/jmgilman/nix-cue
    - mschwaig 4y ago
      Theoretically languages other than Nix can be used to generate derivations and from that point forward to the finished build result everything should work the same way. There is already some experimental setup for Nix to call Nickel for producing derivations using a function call importFromNcl. A more language-agnostic FDI (foreign derivation interface?) would be really exciting. When writing Nix code it can often feel quite opaque what's going wrong, so writing actual package descriptions in a more constrained language like CUE, at least to me, feels like it might help. Better tooling in Nix and the kind of validation that Nickel proposes also look like good bets. I'm glad there is more than one horse in the race to improve the ecosystem. I have been wondering for some time what would be required to define a package set just like nixpkgs in CUE (since it's not lazy and not touring complete). I only have very vague thoughts on that, so I would love reading about it from someone who knows more about how nixpkgs works or someone actually trying it.
flurie 4y ago
The big thing this is going to miss between 2018 and now is that flakes have greatly increased presence. The small things are: - nix-direnv[1] is much more powerful and stable, with or without flakes - devshell[2] exists and is reasonably mature for those who want to give this to a team without teaching them (most) nix Still, apart from those, this is still a good intro. [1] https://github.com/nix-community/nix-direnv https://github.com/nix-community/nix-direnv [2] https://github.com/numtide/devshell https://github.com/numtide/devshell
- JamesSwift 4y ago
  Yeah, I checked the date after seeing a lack of flakes and sure enough: 2018. If you are new to nix I 100% recommend starting with flakes. It simplifies so much for a newbie, e.g. no management of NIX_PATH and simple upgrades (`sudo nix upgrade-nix`). It also enables essentially single-line machine bootstrap on a new box even if you use home-manager.
  - flurie 4y ago
    Do you know of any basic nix tutorials that skip the non-flake world? I'm not sure that they exist, but I think they could be really helpful. A lot of confusion when adopting flakes seems to come from the fact that the terrible UX of the old nix commands doesn't map cleanly to the (not perfect but visibly improved) new commands. Why learn this... nix-env -iA nixpkgs.hello ...when you can learn this instead? nix profile install nixpkgs#hello
    - JamesSwift 4y ago
      I have no idea, I have been with nix for long enough that I hadn't sought anything like that out. I should note that flakes are still technically experimental (i.e. opt-in), and theres still some community drama around not wanting to go with flakes mainly by longtime nix users. Also note that the "modernized" `nix` CLI interface is experimental/opt-in as well vs the out-of-the-box "legacy" commands (e.g. nix-env). So yeah, its a bit of an odd time in nix land as they transition but I don't see any indication that you would be poorly served or burned by moving to both nix command and flakes now.
GoOnThenDoTell 4y ago
Is there a good book that explains Nix, from theory to real world dev usage?
- qbasic_forever 4y ago
  I've gotten into it recently by skimming the docs, then diving in and using flakes. All of this from a multi-user/single user install on linux, I'm not ready to jump into managing the full OS yet. But IMHO I would try to take a flake centric approach because there's a _ton_ of cruft in the docs about stuff like channels that all gets completely jettisoned and dropped once flakes are the norm. It's just a lot of concepts and CLI commands, flags, rituals, etc. in the docs that will give you nothing of value in a flakes world. Unfortunately there are no real docs that make this clear that the nix world is deep into a major transition and flakes are the clear future. This 1 page intro to the nix language was all I needed to get comfortable with it too: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p It's really a pretty simple data-oriented language when you get down to it.
  - JamesSwift 4y ago
    > It's really a pretty simple data-oriented language when you get down to it Yes, if you think of nix-the-language as a bunch of helpers that creates a big key-value JSON object then you will start to get a better mental model.
  - massysett 4y ago
    This is what scares me off from Nix every single time. Even the biggest Nix fans keep saying that the docs are terrible. When I do try Nix people say “oh don’t do it that way, even though that’s what the docs say, now the way to do it is this new way.” I can never imagine how Nix is going to help me enough to make it worthwhile to endure this hazing.
    - qbasic_forever 4y ago
      It's aggravating and kept me away from it for a while too. Try out small isolated parts of it like nix-shell and the flakes version of it nix develop. You can play with that stuff without having to dive in and commit moving all your existing home and other environments to it. Basically just get a little sandbox going to experiment with until you're more confident in doing more with it (or you might find you don't need it and didn't waste much effort/time).
transfire 4y ago
Oh, how I miss Gobo.
elt 4y ago
I have used Nix in the past and enjoyed it... for a while. I will go against the grain and suggest not using it, especially for native projects of any kind (C, C++, Go, etc). In my case I was doing Go work, but the binaries that are built are usually alright, unless you require Cgo and libc gets linked dynamically (Go will do this without telling you). Suddenly that binary won't work on production! It broke my server and I had to force static compiling so Nix's libc wouldn't be linked dynamically. This can happen in Go if you do something like look up the user's home directory or cache directory, etc. Suddenly your Go binary is dynamically linked...
- baby 4y ago
  We use it for OCaml because there’s nothing in OCaml that really exist to manage dependencies and build (opam and dune are awful). But it doesn’t work well with our Rust dependency. I think it could work well with our Rust dependencies (which needs to be packaged with a derivation and thus doesn’t work in a nix develop shell) if nix stops where Cargo begins, but it seems like it is not nix’s philosophy.
  - WastingMyTime89 4y ago
    What do you miss from opam (dune is a build system - nothing to do with dependencies)? Last time I checked it did pretty much everything you might need and was fairly pleasant to use.
    - speed_spread 4y ago
      To say that a build system has nothing to do with dependencies is pretty telling about the OCaml tooling mindset.From Maven to Cargo, almost every modern build system integrates dep management. Only C/C++ is still lagging in that regard.
      - WastingMyTime89 4y ago
        It’s not lagging. How you install dep as conceptually nothing to do with how you link and build. You can tell dune to use dependencies installed with opam easily enough and opam takes care of managing and locking transitive dep. These are entirely different concerns. I am tempted to say "Kids these days" but that wouldn’t be condescending enough.
oxff 4y ago
Nix documentation is such a clusterfuck. You have to basically forage some kind of "most up2date understanding" of basic best practices from random ass blogposts / digging into other people's configs. This is a major red flag.
- slightknack 4y ago
  In my opinion, writing derivations in Guile Scheme, using Guix[0], is a breath of fresh air[1]. If only the ecosystem were as large as Nix's... [0]: https://en.wikipedia.org/wiki/GNU_Guix https://en.wikipedia.org/wiki/GNU_Guix [1]: https://goto.isaac.sh/guix https://goto.isaac.sh/guix
- dizhn 4y ago
  This is what I gathered too. Though I found people on Discord more helpful than the blog posts since things tend not to work as written in those posts anyway.
- baby 4y ago
  The Nix developers should really really take a look at Cargo/Go and learn from developer-friendly tools. The fact that nix is hosted on nixos.org which seems to be completely unrelated to nix shows that they do not understand (yet) how to market their tool, and today every project/company is a media company. You need to learn how to sell your product, and how to improve the dev experience.
dizhn 4y ago
I tried to understand nix a few times but a they seem to be in a transition period.(Albeit one that has taken years already) They want to move to flakes which people here are recommending but it requires setting an experimental state. The documentation you can find is out of date with what people are recommending right now. Even the command to install a package in the official docs is now apparently the wrong thing to do. (This is not related to flakes) In the end I didn't have time to separate what's current and what's not in the documentation. People seem to have carved out bits of nix that sort of works for what they need and called it a day. Which is of course fine as long as it works. I will give it another look in 2 years.
- otabdeveloper4 4y ago
  People have different use-cases for Nix. If you're running a CI/CD server your definition of "installing a package" is vastly different from someone who just wants to install Chrome on their machine.
lukewiwa 4y ago
For me at least the Nix ship has sailed. I'm all in on containers for both prod and local dev environments. Yeah the MacOS performance for volume mounting sucks but we can largely cope. If the Nix story was more together a few years ago I might have been swayed. Currently though containers is good enough. Who knows maybe it is worth using Nix when it comes to ARM devices. We'll see I guess.
- otabdeveloper4 4y ago
  Nix is a great way to build containers (or much saner than Dockerfiles, at least), so your comment seems weird.
zuzuleinen 4y ago
For bob[1], we are using Nix to install dependencies for a project. So far it's working like a charm, the only problem I have besides the Nix documentation which is spread all over the place is that if you want to write Nix expressions yourself to build packages which are not on Nixpkgs[2] binary cache gather all the patience you can muster. [1] https://bob.build/docs/getting-started/package-management https://bob.build/docs/getting-started/package-management [2] https://search.nixos.org/packages https://search.nixos.org/packages

119 points by Arubis 4y ago

cglong 4y ago

(2018)

galaxyLogic 4y ago

Does it work on Windows?

chriswarbo 4y ago
It works under WSL. I seem to remember some other experiments years ago (maybe cygwin/mingw based?)
breakds 4y ago
We use NixOS and Nix extensively in the company. A few developers actually use NixOS on WSL as daily driver, and it was pretty smooth.
pxc 4y ago
There's a community port of NixOS to WSL2, complete with systemd support, plus Docker Desktop support and some other goodies: https://github.com/nix-community/NixOS-WSL https://github.com/nix-community/NixOS-WSL Nix also works on other WSL distros, provided they're using WSL2. Nix supports cross-compiling Windows binaries as well. I know some people use it for that. There is no 'native' support— you can't use Nix as an alternative to Winget or Chocolatey on Windows. Right now a lot of important stuff in Nixpkgs depends on a POSIX shell and Unix coreutils implementation for the basic build environment, and that's shared between many operating systems. Trying to fit Windows into that doesn't really make sense, and there's not really any momentum behind the idea of using any particular other runtime environment (could be a scripting language instead of a shell + coreutils) for those basic builders. But it's conceivable that some day, one or more companies using Nix on WSL might see vaiue in taking that extra step and put together a Nix-based package collection for Windows and help get the Nix Windows port out the door. It also seems possible that a motivated Nix developer could take it somewhere on their own, since at least one has a workable PoC IIRC (but they didn't want to create/maintain a separate package collection). For now, it works very well with WSL2 and that's the way to go for Windows users.

Arubis 4y ago

I've _tried_ going down this route a couple times, with mixed success. Thus far the best experience has been with [lorelei](https://github.com/shajra/direnv-nix-lorelei https://github.com/shajra/direnv-nix-lorelei), which does a decent job making Nix and Direnv play nice and being relatively transparent and forgettable once set up. Still feels like I don't know what's going on under Nix's hood, though. That syntax...

lijogdfljk 4y ago
Some of that functionality is built into Nix/Flakes now.. i believe. Ie i used to use Lorelei but these days i just use Nix and Flakes with Direnv directly. Not sure even how it works, but it works great. But i use Flakes through my entire setup, so i imagine that's why.
flurie 4y ago
nix-direnv[1] is pretty seamless and performant once you have direnv installed and set up. I have a devshell flake template that looks similar to theirs. I had an edge case bug that I was dealing with, and they had a release that fixed it shortly after I reported it. [1] https://github.com/nix-community/nix-direnv#flakes-support https://github.com/nix-community/nix-direnv#flakes-support

lijogdfljk 4y ago

As an aisde, i love Nix, but i hate the lack of types. It's such a chore to figure out what fields are on a value, is the value a func, what are the docs for that func, etc. I have high hopes for Nickel[1] [1]: https://www.tweag.io/blog/2022-03-11-nickel-first-release/ https://www.tweag.io/blog/2022-03-11-nickel-first-release/

flurie 4y ago
I know Eelco hasn't been heavily involved in Nickel, but I have to wonder what his departure from Tweag[1] means for it. A lot of bleeding-edge Nix adherents are starting to adopt CUE[2][3]. [1] https://discourse.nixos.org/t/tweag-nix-dev-update-33/20048 https://discourse.nixos.org/t/tweag-nix-dev-update-33/20048 [2] https://cuelang.org/ https://cuelang.org/ [3] https://github.com/input-output-hk/bitte https://github.com/input-output-hk/bitte
- Cedricgc 4y ago
  Interested in hearing more about CUE+Nix Considering the tight integration between Nix language v. Nixpkgs v. Nix program I mostly see CUE usable to generate data files but would eventually need to be consumed in a .nix config at some point
  - flurie 4y ago
    You're basically right. I'm not 100% sold on this idea, but I think it's a possibility. Most of what I'm seeing right now is CUE facing outward, e.g., to generate typed things from within nix. This[1] is a good example of that. Given how flexible CUE is, and given how similar nix is to HCL, I think it's possible to have CUE emit nix and provide some basic typing that way. [1] https://github.com/jmgilman/nix-cue https://github.com/jmgilman/nix-cue
  - mschwaig 4y ago
    Theoretically languages other than Nix can be used to generate derivations and from that point forward to the finished build result everything should work the same way. There is already some experimental setup for Nix to call Nickel for producing derivations using a function call importFromNcl. A more language-agnostic FDI (foreign derivation interface?) would be really exciting. When writing Nix code it can often feel quite opaque what's going wrong, so writing actual package descriptions in a more constrained language like CUE, at least to me, feels like it might help. Better tooling in Nix and the kind of validation that Nickel proposes also look like good bets. I'm glad there is more than one horse in the race to improve the ecosystem. I have been wondering for some time what would be required to define a package set just like nixpkgs in CUE (since it's not lazy and not touring complete). I only have very vague thoughts on that, so I would love reading about it from someone who knows more about how nixpkgs works or someone actually trying it.

flurie 4y ago

The big thing this is going to miss between 2018 and now is that flakes have greatly increased presence. The small things are: - nix-direnv[1] is much more powerful and stable, with or without flakes - devshell[2] exists and is reasonably mature for those who want to give this to a team without teaching them (most) nix Still, apart from those, this is still a good intro. [1] https://github.com/nix-community/nix-direnv https://github.com/nix-community/nix-direnv [2] https://github.com/numtide/devshell https://github.com/numtide/devshell

JamesSwift 4y ago
Yeah, I checked the date after seeing a lack of flakes and sure enough: 2018. If you are new to nix I 100% recommend starting with flakes. It simplifies so much for a newbie, e.g. no management of NIX_PATH and simple upgrades (`sudo nix upgrade-nix`). It also enables essentially single-line machine bootstrap on a new box even if you use home-manager.
- flurie 4y ago
  Do you know of any basic nix tutorials that skip the non-flake world? I'm not sure that they exist, but I think they could be really helpful. A lot of confusion when adopting flakes seems to come from the fact that the terrible UX of the old nix commands doesn't map cleanly to the (not perfect but visibly improved) new commands. Why learn this... nix-env -iA nixpkgs.hello ...when you can learn this instead? nix profile install nixpkgs#hello
  - JamesSwift 4y ago
    I have no idea, I have been with nix for long enough that I hadn't sought anything like that out. I should note that flakes are still technically experimental (i.e. opt-in), and theres still some community drama around not wanting to go with flakes mainly by longtime nix users. Also note that the "modernized" `nix` CLI interface is experimental/opt-in as well vs the out-of-the-box "legacy" commands (e.g. nix-env). So yeah, its a bit of an odd time in nix land as they transition but I don't see any indication that you would be poorly served or burned by moving to both nix command and flakes now.

GoOnThenDoTell 4y ago

Is there a good book that explains Nix, from theory to real world dev usage?

qbasic_forever 4y ago
I've gotten into it recently by skimming the docs, then diving in and using flakes. All of this from a multi-user/single user install on linux, I'm not ready to jump into managing the full OS yet. But IMHO I would try to take a flake centric approach because there's a _ton_ of cruft in the docs about stuff like channels that all gets completely jettisoned and dropped once flakes are the norm. It's just a lot of concepts and CLI commands, flags, rituals, etc. in the docs that will give you nothing of value in a flakes world. Unfortunately there are no real docs that make this clear that the nix world is deep into a major transition and flakes are the clear future. This 1 page intro to the nix language was all I needed to get comfortable with it too: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p It's really a pretty simple data-oriented language when you get down to it.
- JamesSwift 4y ago
  > It's really a pretty simple data-oriented language when you get down to it Yes, if you think of nix-the-language as a bunch of helpers that creates a big key-value JSON object then you will start to get a better mental model.
- massysett 4y ago
  This is what scares me off from Nix every single time. Even the biggest Nix fans keep saying that the docs are terrible. When I do try Nix people say “oh don’t do it that way, even though that’s what the docs say, now the way to do it is this new way.” I can never imagine how Nix is going to help me enough to make it worthwhile to endure this hazing.
  - qbasic_forever 4y ago
    It's aggravating and kept me away from it for a while too. Try out small isolated parts of it like nix-shell and the flakes version of it nix develop. You can play with that stuff without having to dive in and commit moving all your existing home and other environments to it. Basically just get a little sandbox going to experiment with until you're more confident in doing more with it (or you might find you don't need it and didn't waste much effort/time).

transfire 4y ago

Oh, how I miss Gobo.

elt 4y ago

I have used Nix in the past and enjoyed it... for a while. I will go against the grain and suggest not using it, especially for native projects of any kind (C, C++, Go, etc). In my case I was doing Go work, but the binaries that are built are usually alright, unless you require Cgo and libc gets linked dynamically (Go will do this without telling you). Suddenly that binary won't work on production! It broke my server and I had to force static compiling so Nix's libc wouldn't be linked dynamically. This can happen in Go if you do something like look up the user's home directory or cache directory, etc. Suddenly your Go binary is dynamically linked...

baby 4y ago
We use it for OCaml because there’s nothing in OCaml that really exist to manage dependencies and build (opam and dune are awful). But it doesn’t work well with our Rust dependency. I think it could work well with our Rust dependencies (which needs to be packaged with a derivation and thus doesn’t work in a nix develop shell) if nix stops where Cargo begins, but it seems like it is not nix’s philosophy.
- WastingMyTime89 4y ago
  What do you miss from opam (dune is a build system - nothing to do with dependencies)? Last time I checked it did pretty much everything you might need and was fairly pleasant to use.
  - speed_spread 4y ago
    To say that a build system has nothing to do with dependencies is pretty telling about the OCaml tooling mindset.From Maven to Cargo, almost every modern build system integrates dep management. Only C/C++ is still lagging in that regard.
    - WastingMyTime89 4y ago
      It’s not lagging. How you install dep as conceptually nothing to do with how you link and build. You can tell dune to use dependencies installed with opam easily enough and opam takes care of managing and locking transitive dep. These are entirely different concerns. I am tempted to say "Kids these days" but that wouldn’t be condescending enough.

oxff 4y ago

Nix documentation is such a clusterfuck. You have to basically forage some kind of "most up2date understanding" of basic best practices from random ass blogposts / digging into other people's configs. This is a major red flag.

slightknack 4y ago
In my opinion, writing derivations in Guile Scheme, using Guix[0], is a breath of fresh air[1]. If only the ecosystem were as large as Nix's... [0]: https://en.wikipedia.org/wiki/GNU_Guix https://en.wikipedia.org/wiki/GNU_Guix [1]: https://goto.isaac.sh/guix https://goto.isaac.sh/guix
dizhn 4y ago
This is what I gathered too. Though I found people on Discord more helpful than the blog posts since things tend not to work as written in those posts anyway.
baby 4y ago
The Nix developers should really really take a look at Cargo/Go and learn from developer-friendly tools. The fact that nix is hosted on nixos.org which seems to be completely unrelated to nix shows that they do not understand (yet) how to market their tool, and today every project/company is a media company. You need to learn how to sell your product, and how to improve the dev experience.

dizhn 4y ago

I tried to understand nix a few times but a they seem to be in a transition period.(Albeit one that has taken years already) They want to move to flakes which people here are recommending but it requires setting an experimental state. The documentation you can find is out of date with what people are recommending right now. Even the command to install a package in the official docs is now apparently the wrong thing to do. (This is not related to flakes) In the end I didn't have time to separate what's current and what's not in the documentation. People seem to have carved out bits of nix that sort of works for what they need and called it a day. Which is of course fine as long as it works. I will give it another look in 2 years.

otabdeveloper4 4y ago
People have different use-cases for Nix. If you're running a CI/CD server your definition of "installing a package" is vastly different from someone who just wants to install Chrome on their machine.

lukewiwa 4y ago

For me at least the Nix ship has sailed. I'm all in on containers for both prod and local dev environments. Yeah the MacOS performance for volume mounting sucks but we can largely cope. If the Nix story was more together a few years ago I might have been swayed. Currently though containers is good enough. Who knows maybe it is worth using Nix when it comes to ARM devices. We'll see I guess.

otabdeveloper4 4y ago
Nix is a great way to build containers (or much saner than Dockerfiles, at least), so your comment seems weird.

zuzuleinen 4y ago

For bob[1], we are using Nix to install dependencies for a project. So far it's working like a charm, the only problem I have besides the Nix documentation which is spread all over the place is that if you want to write Nix expressions yourself to build packages which are not on Nixpkgs[2] binary cache gather all the patience you can muster. [1] https://bob.build/docs/getting-started/package-management https://bob.build/docs/getting-started/package-management [2] https://search.nixos.org/packages https://search.nixos.org/packages