17 ms·

How to Learn Nix

150 points by brendanfalk 5y ago

3np 5y ago
(2021) Previously: https://news.ycombinator.com/item?id=29303641 https://news.ycombinator.com/item?id=29303641
yewenjie 5y ago
My two-cents for learing Nix: 0. Give up the expectation of figuring it out quick 1. Read the official manual instead of tutorials 2. Read example configurations from public repos
- dotancohen 5y ago
  This is how I like to learn most technologies. If e.g. a language does not have proper documentation but rather a bunch of almost-blog-post tutorials, then I have no interest in learning it. That said, some tech goes too far. You'll never learn C++ by reading the standards.
- colordrops 5y ago
  #2 was the main thing that worked for me. Also, IRC.
  - ninjin 5y ago
    Indeed, we are a fair few in #nixos@irc.libera.chat and people are welcome to drop by.
    - ltultraweight 5y ago
      To be fair to newcomers: More people are active in the matrix channel nowadays. https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos-org-migrating-from-freenode/13166 https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos...
- doliveira 5y ago
  Yeah, most tutorials and posts about Nix do have the same feeling as the (in)famous monad explanations
- houzi 5y ago
  Wrt to 1), how often do you reckon a beginner is faced with: > By default, `args` is a set of derivation names denoting derivations in the active Nix expression. These are realised, and the resulting output paths are installed. ?? - I think the author really hits the nail on the head with this point.
yoloyoloyoloa 5y ago
Ive tortured myself with Gentoo enough thank you.
- otabdeveloper4 5y ago
  Nix is not a Linux distribution. Nix is like a kind of Docker from an alternative universe. Or maybe "Python venv on massive steroids".
  - lgas 5y ago
    True, though NixOS is a linux distribution, if you want to go that way.
  - southpawflo 5y ago
    to preface, I'm not saying that you don't know this, but maybe for others: gentoo is not a linux distro either (from a certain point of view), more a meta-distribution, where you use the package manager (portage) to build everything from source. fun fact: docker uses alpine linux, which for a while was a gentoo build, until it got to a point where it could bootstrap itself.
    - otabdeveloper4 5y ago
      Nix is very often used for running CI/CD and as a build system for software artifacts. I don't think anybody uses Gentoo for this.
  - chriswarbo 5y ago
    > Nix is like a kind of Docker from an alternative universe. Nix is often compared to Docker, but Docker is essentially just a way to run programs (in a sandbox). Saying "I'll build it with Docker" says how you're going to run it, but not what you're going to run. Unfortunately, the "what" usually turns out to be a shell script, which runs one package manager to fetch another package manager, downloads a bunch of files from some random URLs, etc. Nix is all about keeping careful track of the dependencies between things, such that all the fetching has been done by the time our scripts start (access to the network, and any paths outside the build sandbox, is disabled by default). Also, the way Docker tends to be used involves downloading an entire Linux distro, just to run those scripts. Nix does the opposite: scripts only have access to precisely what they've asked for.
notemaker 5y ago
Something that's helped me a lot recently (after ~9 months of using nixos) is to actively look in nixpkgs to see what options a package exposes. For example, determining if and how your desktop environment can enable Wayland support.
benreesman 5y ago
Nix is advanced alien technology that was badly damaged when it fell from the sky. In particular the docs/blogs/forums are net negative some ridiculously high amount of the time, like start composing an email: “I have a very special set of skills, and I will find you…” amount of the time. But once it starts working: how does anyone do this any other way? - The language is reasonably well-documented and those docs are rarely wrong. - Learn bash, like really really learn bash. - Check out nixpkgs and use that to figure out how to do stuff. - Only do this if paying the entire cost in time and frustration in one aneurism-inducing spasm upfront is a worthwhile tradeoff for having everything work perfectly every time thereafter. It’s kinda like being Paul Atriedes: you get magic powers but first you put your hand in the fucking box. What’s in the box? “Nix!”
- epage 5y ago
  Something Nix seriously needs is a searchable index of people's nix configs. When I attempted to use it, I had tabs open for around 10 configs that I was cross referencing but I can't find that list of configs anymore and I have more obscure packages I'm trying to figure out how to use and don't want to manually search. This is on top of a GUI (syncs with git repos, at minimum about:config like with the documentation inline and ability to edit free-form entries), a Nix-style installer (pulls your config from a git host, inline machine profile editor, formatting help and saves formatting to repo), maybe some languages improvements, etc
  - 42642626 5y ago
    https://pastebin.com/raw/RkZvsKuL https://pastebin.com/raw/RkZvsKuL This is my current list. I add them as a submodule to a repo. ag -A10 'inputs' -G flake.nix
    - benreesman 5y ago
      That is absolutely fantastic. Have you thought about putting that somewhere it will rank on Gooogle?
mcbuilder 5y ago
Reading this was a bit maddening at times, because, for instance, the author always seemed to give up after 15 seconds of a command executing with not much explanation. A bit meandering.
- jkonline 5y ago
  I think you've identified one of the author's many not-so-subtle (but still somehow obscure) themes. Next I want to write, "For me, I enjoyed it," but I hesitated initially, because I'm surprised that I'm not more annoyed.
- dmitriid 5y ago
  > for instance, the author always seemed to give up after 15 seconds of a command executing with not much explanation Because he recreates the experience of an average user who comes into nix. To quote, --- start quote --- nix-env invocations are too slow for anyone to reasonably use Nix as a package manager. Full stop. Every. Single. Command. 30 seconds. It was unbearable. I mean, it was nice for writing this blog post – plenty of time to get my thoughts down – but if I were an actual, normal user? Trying to use Nix? I would just stop. My Nix adventure would end before I finished running the first command. Because I would assume it was broken, ctrl-C outta there, and go back to using Homebrew (or pacman, or apt, or whatever). --- end quote ---
shantnutiwari 5y ago
The Nix hype machine comes up on HN every few weeks. As someone who tried Nix-- never understood what the big selling point is-- what can Nix do my existing tools can't? (without me spending 6 months) Nix can create isolated environments, but as far as I see, you can only install the tools Nix repo supports. And the official examples only give toy examples --here's a simple python script you can run with Nix-- but I can just run this simple script in a virtual env, or docker if I have 2-3 different scripts. What problem is Nix solving? What pain does it fix that is so important it would justify me spending 6 months on it? And then there is NixOS, which again, I have no idea-- I can create my own Linux distribution that is what, reproducible? Again, is this a real problem anyone faces (and that isnt fixed by docker or ansible or any of the other hundreds of tools)? My point is: Why is Nix getting so much hype when I dont see them solving any real problems? Sure, they promise a lot, but I have yet to see any real solutions. Hence the Nix Hype Machine
- IshKebab 5y ago
  I don't know how you managed to try it without realising its selling points. It's written in huge text at the top of the home page: > Reproducible builds and deployments > Learn how to make reproducible, declarative and reliable systems.
  - cies 5y ago
    He does not understand those words I'm afraid. Maybe he just did not run into problems with non-reproducible builds yet. Give him time :)
- rkangel 5y ago
  I use Nix in a very simple way - reproducible dev environments. This is very similar to what you might do with Docker - have the right version of the right dev tools. The result is much more user friendly though because it's layered "over the top" of my normal environment rather than being it's own world (but if I want to run things in their own world I can just run nix shell with --pure). I can then use that same environment to do CI without even creating a docker image, e.g. this for Gitlab CI: image: nixos/nix:latest before_script: - nix-env -f shell.nix -i -A buildInputs If the amount of stuff is big, or you need to build things rather than get them out of Nix cache, then you can build the docker image using Nix tooling instead. You can also use Nix to control what is on a machine. E.g. for our lab setup we had a gateway machine behind which was all the test equipment. NixOS was great for having the exact config of that machine checked into version control so we could recreate it. It's far more reliable than Ansible or something like that.
jibbit 5y ago
Really enjoyed this and feel like this could be an excellent format for learning all kinds of things. I really hope it pushes on to the logical conclusion. Asking a lot, I know.
account-5 5y ago
Novice here. Can someone explain to me why I'd use this over say docker, ansible, or even a make file? BTW I'm no expert in any of the aforementioned, I've had to use docker, was thinking of learning about make files, and wanted to look at ansible, maybe.
- alduin32 5y ago
  Nix allows to have a "declarative" approach to configuration management, whereas Ansible uses a more "imperative" approach. For example, applying a Nix configuration is more-or-less guaranteed to be an idempotent operation, while this is not guaranteed at all using Ansible : many Ansible modules are not idempotent at all. This brings many useful features, for example the ability to rollback to a previous state, or more generally the ability to have some determinism in configuration management of complex systems. Nix and Docker can be combined together, I have many hosts where some services run in Docker containers, where the Dockerfile is defined in the Nix configuration itself, or generated by composing the upstream Dockerfile with my own configuration values.
- rgoulter 5y ago
  Loosely, I'd compare it to using Emacs or Vim instead of VSCode. You'll have a steeper learning curve, but it has power-user benefits.
- ParetoOptimal 5y ago
  > Can someone explain to me why I'd use this over say docker, ansible, or even a make file? Better reproducability by default. Docker containers usually have drift from `apt update` and that can let the "works on my machine creep in". You can avoid this in your own Docker containers, but you can't fix the whole ecosystem using that approach. The nix ecosystem avoids this drift and other sources of repriducability issues like the plague. If he is very popular Technologies with very common workflows, Nix might not seem worth it since the sharp edges from the lack of reproducibility have been filed down by brute force. You might find as soon as you need to do something slightly different, or need to get around a bug right now, you'll want Nix.
BoardsOfCanada 5y ago
I've tried for a couple of days now to set up nix for reproducible iOS builds at work and I'm close to tears. - Examples that just don't work. - Commands that run and no output is given, even though the text I'm following says it should output information I need. - Do I need nix-darwin? Well, the readme explains what it is: "Nix modules for darwin, /etc/nixos/configuration.nix for macOS." What? (Finally I found an answer at Stack overflow, and it seems I don't need it. Seems to be kind of NixOS on top of macOS) - Can't build with nix-build. After long time searching it seems like you're supposed to run nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' - shouldn't there be a simpler way for this common case? - An issue open since 2018 that the manuals simple example doesn't build: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 People chiming in years later that they only could build the example after reading the suggestions in that issue. - And now I can't start my nix-shell because it says there's a problem with SSL certificates. I'm giving up.
- Shoue 5y ago
  > - Can't build with nix-build. After long time searching it seems like you're supposed to run nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' - shouldn't there be a simpler way for this common case? This is because the default.nix you have is exporting a lambda that expects arguments to be saturated, `callPackage` does this for you automagically hence why you have to use it. Instead you probably want the nixpkgs import line _inside_ default.nix, either in a let-in binding or using the `?` operator to default a lambda argument to something, usually nixpkgs itself bound to a `pkgs` argument so you can use `pkgs`[0]. Even better, you can use Niv to pin nixpkgs to a specific nixpkgs commit so that it doesn't change as you update your system's nixpkgs channel with the `nix-channel` command because `<nixpkgs>` is special syntax referring to what's stored in your $NIX_PATH[1]. [0]: see the default argument section: https://nixos.wiki/wiki/Nix_Expression_Language https://nixos.wiki/wiki/Nix_Expression_Language [1]: https://nixos.org/guides/nix-pills/nix-search-paths.html https://nixos.org/guides/nix-pills/nix-search-paths.html
  - pmarreck 5y ago
    You provided what is probably a logical explanation but didn't answer the question in the way he meant it (I think), which is: Addressing common use-cases should be a simple matter. Addressing complex use-cases should ALSO be a simple matter ideally, but is permitted to be a complex matter. Here we have a case where a common use-case is addressed by a complex-seeming solution (unless you are essentially "degreed" in Nix, apparently, and understand exactly why partial function application won't work here or whatever). Or are you saying he's actually doing it wrong and built the nix file wrong? I'm about to dive headfirst into this nix business and this is intimidating, lol
alduin32 5y ago
I've found the Nix language to be a really useful configuration language, even "outside" of the NixOS ecosystem. I reuse nixpkgs's module system, but to describe things that are used outside of the NixOS system (for example in an Ansible playbook). For example, I'm using it to describe a set of containers and services in my infrastructure, and it allows me to properly describe the interfaces between the different components of the infrastructure, using several modules : - a "base" module defines the options used for describing the services - one defines the services themselves - one handles the reverse proxy configuration for these services (for multiple frontends), as well as the SSL certificates and DNS zones - one handles the containers themselves (through Docker or LXD) - one handles the networking overlay - one handles the "shared services" (databases, caches, etc) Each of these modules is basically a function that takes the resulting configuration as argument, allowing it to reuse values defined by the other modules, and the configuration itself is the fixpoint of the composition of all of these functions. It all composes quite well, and the nixpkgs module system allows me to document the options provided by each module. I can even reuse some of the existing NixOS to create a web interface where other admins can search for configuration options and lookup their documentation. Some things are exported in JSON, some are used directly as NixOS modules, some things source the inventory for Ansible playbooks, etc. It allowed me to create a well-defined source of truth for a very heteregenous architecture, while preserving some of the existing workflows and tooling. It's not ideal of course : Nix itself is not typed, the nixpkgs module system provides some typing, but the integration is not perfect, and this makes error handling quite tedious. Also, the interpreter is quite slow, there is no documented way to embed it into your own program, and I
seqizz 5y ago
I'm using nixos for years, still couldn't grasp the language itself enough. I accepted that it's not for us, who are not familiar with functional programming. Like, what is even this: https://github.com/Ryunaq/dotfiles/blob/b132f79e2042d6ef75008d666ba12306ad21d427/flake.nix#L60-L66 https://github.com/Ryunaq/dotfiles/blob/b132f79e2042d6ef7500...
- deleted 5y ago
  [deleted]
- chriswarbo 5y ago
  It's a list of "overlays" (functions of two arguments, which return a key/value set). Overlays make it easy to overrides and replace things. If you prefer imperative programming, then think of it being used like this: const result = defaultNixpkgsSet; for (overlay in overlays) { // Merge the overlay's return value into the results value result := result.merge(overlay( result, // Give each overlay a reference to result result.copy() // Also give a snapshot of the contents so-far )) } return result; Consider an overlay something like this: function(result, snapshot) { return { maven = snapshot.maven.override({ jre = result.jre8; }) }; } Merging this into the 'result' will replace the 'maven' definition. That new definition is the same as the old one ('snapshot.maven'), but it will be using 'jre8' instead of the default. Two things to note: - We're using 'result.jre8', which will include any overrides made to 'jre8' (by other overlays, even those being applied after this one!) - We're using 'snapshot.maven', since using 'result.maven' would cause an infinite loop (since 'result.maven' depends on the output of this override!) In that link, they're calling their arguments 'final' and 'prev' instead of 'result' and 'snapshot', but the idea's the same. Most overlays call their arguments 'self' and 'super', but I avoided them in this explanation since those names have specific meanings in other languages (they're literally just variable names in Nix).
  - zaphar 5y ago
    the result infinite loop issue is easily the most confusing part of nix. It works because nix is a lazy functional language. But I'm not particularly sold on that laziness being useful since it leads to awkward hacks like the two arguments to an overlay function. It has the one benefit of allowing you to not care about the order that overlays get called in. However it does that by giving your code magical come from semantics that make debugging a problem harder than it needs to be. I think the nix lazy semantics would actually have been better left out in favor of clearer dependency semantics. In a way the clearer dependency semantics of flakes are are driving the reason they are increasing in adoption so much. In essence they work around the problems introduced by overly clever usage of laziness in a nix package.
pmarreck 5y ago
Perfectly timed as I literally JUST started my (second ever?) Nixos attempt
michael_j_ward 5y ago
I spent like ~6 hours going through the first ~10 chapters of "how to learn nix" and the corresponding docs, and I've built up a decent model of how nix works under the hood but have no knowledge of how to do the things I want to do (reproducible dev environment per project) Hopefully that'll come in the next ~10 hours, or maybe I need to switch to one of these other learning resources - Tutorial motivated by accomplishing things [0] - Learn nix language syntax [1] - If video is more your thing [2] - The official "bite-sized guide" Nix Pills [3] [0] https://nix.dev/ https://nix.dev/ [1] https://nixcloud.io/tour https://nixcloud.io/tour [2] https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4... [3] https://nixos.org/guides/nix-pills/#nix-pills https://nixos.org/guides/nix-pills/#nix-pills
- ianthehenry 5y ago
  Since "How to Learn Nix" mirrors the (bonkers) presentation order from the official documentation, I am afraid to say that you will not learn how to do this until part 32, deep into the Nixpkgs manual. https://ianthehenry.com/posts/how-to-learn-nix/builders/ https://ianthehenry.com/posts/how-to-learn-nix/builders/ The Nix manual just doesn't talk about this. But the Nixpkgs manual will, eventually. Here's what it has to say: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-mkShell https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-mkShell That's it. Nix Pills does cover making development environments in chapter 10: https://nixos.org/guides/nix-pills/developing-with-nix-shell.html https://nixos.org/guides/nix-pills/developing-with-nix-shell... But Nix Pills is not really a "bite-sized guide" so much as a "let's motivate and invent the Nixpkgs genericBuilder infrastructure from scratch." So it doesn't really show you an example of how to write shell.nix files. Writing reproducible dev environments per project ("shell.nix files") is the main reason I use Nix. But Nix does not... make it very easy, out of the box. There are two more posts (separate from the documentation-reading sections) that will explain how to make this more ergonomic: - https://ianthehenry.com/posts/how-to-learn-nix/saving-your-shell/ https://ianthehenry.com/posts/how-to-learn-nix/saving-your-s... - https://ianthehenry.com/posts/how-to-learn-nix/nix-zshell/ https://ianthehenry.com/posts/how-to-learn-nix/nix-zshell/ (This is slightly unfair because if you're using Nix to build software, not just create a development environment, you get nix-shell for free. mkShell is sort of a special case of "I don't want the final result in the /nix/store; I just want you to put me in a shell with these packages installed." It's not a case that Nix optimizes very well for, even though it is my primary use case.) Finally, obligatory caveat that everything is completely different now in the "new" (unstable, flakes-based) Nix interface: https://ianthehenry.com/posts/how-to-learn-nix/nix-develop/ https://ianthehenry.com/posts/how-to-learn-nix/nix-develop/
pmarreck 5y ago
https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings did a pretty good Nix (and ZFS) sell. Of course, it was written by a guy who actually works on NixOS...
yoyohello13 5y ago
I see the appeal of Nix, but if your package manager requires a 50 part how-to learn series... At this point I don't really know if the juice is worth the squeeze.
- chriswarbo 5y ago
  I don't think of Nix as a package manager; I think of it like Make. The problem with Make (other than the awful syntax!) is that it's not composable. For example, GCC has a Makefile, with an "install" rule; yet my C project's Makefile can't use that as a dependency; e.g. hello: hello.o installGCC gcc -o hello hello.o hello.o: hello.c installGCC gcc -c hello.c # Pseudocode to import the 'install' rule (renaming as installGCC), from the # Makefile in GCC's source (depends on gccSource to fetch it) @import: gccSource import(gcc-10.1.0/Makefile, install -> installGCC) gccSource: wget 'http://mirror.0xem.ma/gnu/gcc/gcc-10.1.0/gcc-10.1.0.tar.gz' tar xzf gcc-10.1.0.tar.gz Nix solves that problem: we can write a rule (Nix calls them "derivations") which run wget/curl/git/whatever, and we can import files from the result. Nixpkgs (a big collection of definitions for Nix) takes this to its logical conclusion: C programs not only depend on their source, but also on the compiler, the shell used to run the commands, etc. In turn, the compiler depends on its source, and a shell, and a compiler (if it's bootstrapped). The shell depends on its source, and a compiler, and a shell to run the commands, etc. The downloader (usually curl) depends on its source, and a compiler, and a shell, etc. The recursion is cut-off by some "bootstrap binaries" (which the bootstrappable-builds project is trying to shrink even further http://bootstrappable.org http://bootstrappable.org ) With this "composability" problem solved, it turns out there's actually no need for "package managers" at all; or indeed for "installing" anything: each derivation just says what other derivations it depends on. Nix can act like a package manager if you want it to; e.g. its 'nix-env' command manages a "user profile" (a symlink at ~/.nix-profile, which point to the output of a derivation, which itself symlinks to the output of whatever derivations we want "installed"). NixOS works in a similar way, but with a system-wide /run/current-system symlink (plus a massive pile of options to configure things more easily). Hence the slight complexity of Nix (in fact, most of the complexity is in the libraries, like Nixpkgs) lets us do away with build tools (Make, Ninja, Ant, etc.), language package managers (maven, pip, cargo, npm, cabal, etc.), OS package managers (apt, yum, etc.), configuration managers (chef, ansible, puppet, etc.). Nix's "binary cache" mechanism also lets us do away with binary formats like rpm, dpkg, wheel, jar, etc. in a transparent manner (e.g. we can still patch sources, override compiler flags, etc.; we just get a cache-miss) Of course, that's the ideal. There's so much code written with Makefiles, pom.xml files, setup.py files, cargo.toml files, etc. that most Nix definitions just add those tools as dependencies, and let them do the building!
benreesman 5y ago
I think it's really important to have realistic expectations about Nix/NixOS when deciding how much effort to spend on it. It's ridiculously hard to get started. The online resources are simply inadequate: incorrect and/or out-of-date information is basically equally common as useful information. There isn't a good book you can get on Amazon. The "Learn" boards thing is full of "you're doing it wrong" bullshit. The Discord is so-so at best for getting help. For me personally it was somewhere between 1-3 months of being frustrated basically every day and I still want to throw things sometimes. It's basically clone `nixpkgs`, figure out how to get the REPL going, painstakingly reading the code of the stuff that does work, and pain. It says absolutely nothing about how smart/capable/motivated/senior someone is that a week or two in it's like "fuck this". The payoff is outrageous, but the barrier to entry is nowhere near something that can be called "acceptable", let alone "batteries included". I completely understand why a lot of people are all-but-hostile to it. I would budget a minimum of a highly frustrating month working with it every day to start to having the lightbulb moments, and frankly your use case needs to be pretty extreme in one way or another for that to be worth it. A lot of people don't have a friggin month to screw around with a fairly niche infrastructure if what they're doing now works for them. I really, really hope that at some point someone gets serious about making this fairly magical thing even remotely learnable, but right now it's a fucking mess.
- nixpulvis 5y ago
  I think this comment applies to nearly all technology today. If it doesn't have a `man` page, good `-h` notes, or a manual released with each version, I basically assume I'm going to have a hellish time Googling around for anything. This doesn't really solve the issue though, since a lot of manuals written are outdated by sources changes that were rushed and forgotten. We need to come to terms with the fact that the way we as programmers acquire information about our tools is in a dire need of help. Search indices are just not valid references for us. We should never have learned this method of learning in the first place, but it was easy and painless in the beginning. People need to just slow down a bit and become more methodical one thinks.
  - benreesman 5y ago
nixpulvis 5y ago
Also read: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-packages https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... for what is in my opinion one of the most damning issues with Nix. Written by the same author if you didn't notice. In fact, reading over ianthehenry's blog is an interesting adventure in one mans experience learning this new tool.
- aidenn0 5y ago
  IMO, nix-env is a horrible, no-good, very-bad thing. It was also what the manual suggested using for installing packages when I learned nix. I have ditched it on all of my systems and have been so much happier... but there doesn't seem to be a single agreed upon replacement for it. I wrote my own, I'm sure others have well. It seems home-manager is popular, but it's certainly not even close to universally adopted and I've never gotten around to learning it myself. Maybe nix-env -irf does the Right Thing; certainly nobody pointed me at it when I was battling against the evil that is nix-env...
  - nixpulvis 5y ago
    I disagree, I used it a number of times. It's practical. Sometimes you just want to install software the old-fashioned way. You can argue that isn't the right way to do things, and anyone running Nix will probably agree, but still I found myself wanting this and it served the purpose well enough. aidenn0, could you explain what `-irf` does and what it should do? I'm curious now, even though I don't currently use Nix.
    - aidenn0 5y ago
      > I disagree, I used it a number of times. It's practical. Sometimes you just want to install software the old-fashioned way. You can argue that isn't the right way to do things, and anyone running Nix will probably agree, but still I found myself wanting this and it served the purpose well enough. The problem is that it lulls you into thinking it serves the purpose well enough and then eventually things break. Then they get more broken. Then you can't figure out which thing you installed is breaking things. Then you finally do and can't figure out how to uninstall the thing that broke things. > aidenn0, could you explain what `-irf` does and what it should do? I'm curious now, even though I don't currently use Nix. I'm pretty sure it sets up the environment from a file; I found it one link away from the link in the comment I replied to here[1] 1: https://ianthehenry.com/posts/how-to-learn-nix/declarative-user-environment/ https://ianthehenry.com/posts/how-to-learn-nix/declarative-u...
timwis 5y ago
Love the idea of a blog post like this. I tried something very similar a couple weeks ago on a c++ project, both in hopes it might lead to an improved user experience, and also for others struggling to figure it out. https://github.com/valhalla/valhalla/discussions/3540 https://github.com/valhalla/valhalla/discussions/3540
mamoriamohit 5y ago
> Or you just memorize the “right way to do it,” and every time you type it, a part of you wonders why, until eventually your mind crystallizes around this idea that Nix is confusing and weird and too hard for you to figure out. This stands true for most of the things in universe for most of the people.
bluefirebrand 5y ago
My only experience with Nix was one job, where we hired a new guy who had just done his PHD in Computer Science but never written production code. Someone on the team was mentioning that our build/deploy pipeline was a pain in the butt, and it would really be nice to have a proper CI process implemented. PHD spoke up saying he could help with that, and then spent the next three months wrestling with Nix. I left the company before I saw how long it actually took him, though. I saw enough to realize it would likely never be worth my time to use. Sorry Nix.

150 points by brendanfalk 5y ago

3np 5y ago

(2021) Previously: https://news.ycombinator.com/item?id=29303641 https://news.ycombinator.com/item?id=29303641

My two-cents for learing Nix: 0. Give up the expectation of figuring it out quick 1. Read the official manual instead of tutorials 2. Read example configurations from public repos

dotancohen 5y ago
This is how I like to learn most technologies. If e.g. a language does not have proper documentation but rather a bunch of almost-blog-post tutorials, then I have no interest in learning it. That said, some tech goes too far. You'll never learn C++ by reading the standards.
colordrops 5y ago
#2 was the main thing that worked for me. Also, IRC.
- ninjin 5y ago
  Indeed, we are a fair few in #nixos@irc.libera.chat and people are welcome to drop by.
  - ltultraweight 5y ago
    To be fair to newcomers: More people are active in the matrix channel nowadays. https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos-org-migrating-from-freenode/13166 https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos...
doliveira 5y ago
Yeah, most tutorials and posts about Nix do have the same feeling as the (in)famous monad explanations
houzi 5y ago
Wrt to 1), how often do you reckon a beginner is faced with: > By default, `args` is a set of derivation names denoting derivations in the active Nix expression. These are realised, and the resulting output paths are installed. ?? - I think the author really hits the nail on the head with this point.

yoloyoloyoloa 5y ago

Ive tortured myself with Gentoo enough thank you.

otabdeveloper4 5y ago
Nix is not a Linux distribution. Nix is like a kind of Docker from an alternative universe. Or maybe "Python venv on massive steroids".
- lgas 5y ago
  True, though NixOS is a linux distribution, if you want to go that way.
- southpawflo 5y ago
  to preface, I'm not saying that you don't know this, but maybe for others: gentoo is not a linux distro either (from a certain point of view), more a meta-distribution, where you use the package manager (portage) to build everything from source. fun fact: docker uses alpine linux, which for a while was a gentoo build, until it got to a point where it could bootstrap itself.
  - otabdeveloper4 5y ago
    Nix is very often used for running CI/CD and as a build system for software artifacts. I don't think anybody uses Gentoo for this.
- chriswarbo 5y ago
  > Nix is like a kind of Docker from an alternative universe. Nix is often compared to Docker, but Docker is essentially just a way to run programs (in a sandbox). Saying "I'll build it with Docker" says how you're going to run it, but not what you're going to run. Unfortunately, the "what" usually turns out to be a shell script, which runs one package manager to fetch another package manager, downloads a bunch of files from some random URLs, etc. Nix is all about keeping careful track of the dependencies between things, such that all the fetching has been done by the time our scripts start (access to the network, and any paths outside the build sandbox, is disabled by default). Also, the way Docker tends to be used involves downloading an entire Linux distro, just to run those scripts. Nix does the opposite: scripts only have access to precisely what they've asked for.

notemaker 5y ago

Something that's helped me a lot recently (after ~9 months of using nixos) is to actively look in nixpkgs to see what options a package exposes. For example, determining if and how your desktop environment can enable Wayland support.

benreesman 5y ago

Nix is advanced alien technology that was badly damaged when it fell from the sky. In particular the docs/blogs/forums are net negative some ridiculously high amount of the time, like start composing an email: “I have a very special set of skills, and I will find you…” amount of the time. But once it starts working: how does anyone do this any other way? - The language is reasonably well-documented and those docs are rarely wrong. - Learn bash, like really really learn bash. - Check out nixpkgs and use that to figure out how to do stuff. - Only do this if paying the entire cost in time and frustration in one aneurism-inducing spasm upfront is a worthwhile tradeoff for having everything work perfectly every time thereafter. It’s kinda like being Paul Atriedes: you get magic powers but first you put your hand in the fucking box. What’s in the box? “Nix!”

epage 5y ago
Something Nix seriously needs is a searchable index of people's nix configs. When I attempted to use it, I had tabs open for around 10 configs that I was cross referencing but I can't find that list of configs anymore and I have more obscure packages I'm trying to figure out how to use and don't want to manually search. This is on top of a GUI (syncs with git repos, at minimum about:config like with the documentation inline and ability to edit free-form entries), a Nix-style installer (pulls your config from a git host, inline machine profile editor, formatting help and saves formatting to repo), maybe some languages improvements, etc
- 42642626 5y ago
  https://pastebin.com/raw/RkZvsKuL https://pastebin.com/raw/RkZvsKuL This is my current list. I add them as a submodule to a repo. ag -A10 'inputs' -G flake.nix
  - benreesman 5y ago
    That is absolutely fantastic. Have you thought about putting that somewhere it will rank on Gooogle?

mcbuilder 5y ago

Reading this was a bit maddening at times, because, for instance, the author always seemed to give up after 15 seconds of a command executing with not much explanation. A bit meandering.

jkonline 5y ago
I think you've identified one of the author's many not-so-subtle (but still somehow obscure) themes. Next I want to write, "For me, I enjoyed it," but I hesitated initially, because I'm surprised that I'm not more annoyed.
dmitriid 5y ago
> for instance, the author always seemed to give up after 15 seconds of a command executing with not much explanation Because he recreates the experience of an average user who comes into nix. To quote, --- start quote --- nix-env invocations are too slow for anyone to reasonably use Nix as a package manager. Full stop. Every. Single. Command. 30 seconds. It was unbearable. I mean, it was nice for writing this blog post – plenty of time to get my thoughts down – but if I were an actual, normal user? Trying to use Nix? I would just stop. My Nix adventure would end before I finished running the first command. Because I would assume it was broken, ctrl-C outta there, and go back to using Homebrew (or pacman, or apt, or whatever). --- end quote ---

shantnutiwari 5y ago

The Nix hype machine comes up on HN every few weeks. As someone who tried Nix-- never understood what the big selling point is-- what can Nix do my existing tools can't? (without me spending 6 months) Nix can create isolated environments, but as far as I see, you can only install the tools Nix repo supports. And the official examples only give toy examples --here's a simple python script you can run with Nix-- but I can just run this simple script in a virtual env, or docker if I have 2-3 different scripts. What problem is Nix solving? What pain does it fix that is so important it would justify me spending 6 months on it? And then there is NixOS, which again, I have no idea-- I can create my own Linux distribution that is what, reproducible? Again, is this a real problem anyone faces (and that isnt fixed by docker or ansible or any of the other hundreds of tools)? My point is: Why is Nix getting so much hype when I dont see them solving any real problems? Sure, they promise a lot, but I have yet to see any real solutions. Hence the Nix Hype Machine

IshKebab 5y ago
I don't know how you managed to try it without realising its selling points. It's written in huge text at the top of the home page: > Reproducible builds and deployments > Learn how to make reproducible, declarative and reliable systems.
- cies 5y ago
  He does not understand those words I'm afraid. Maybe he just did not run into problems with non-reproducible builds yet. Give him time :)
rkangel 5y ago
I use Nix in a very simple way - reproducible dev environments. This is very similar to what you might do with Docker - have the right version of the right dev tools. The result is much more user friendly though because it's layered "over the top" of my normal environment rather than being it's own world (but if I want to run things in their own world I can just run nix shell with --pure). I can then use that same environment to do CI without even creating a docker image, e.g. this for Gitlab CI: image: nixos/nix:latest before_script: - nix-env -f shell.nix -i -A buildInputs If the amount of stuff is big, or you need to build things rather than get them out of Nix cache, then you can build the docker image using Nix tooling instead. You can also use Nix to control what is on a machine. E.g. for our lab setup we had a gateway machine behind which was all the test equipment. NixOS was great for having the exact config of that machine checked into version control so we could recreate it. It's far more reliable than Ansible or something like that.

jibbit 5y ago

Really enjoyed this and feel like this could be an excellent format for learning all kinds of things. I really hope it pushes on to the logical conclusion. Asking a lot, I know.

account-5 5y ago

Novice here. Can someone explain to me why I'd use this over say docker, ansible, or even a make file? BTW I'm no expert in any of the aforementioned, I've had to use docker, was thinking of learning about make files, and wanted to look at ansible, maybe.

alduin32 5y ago
Nix allows to have a "declarative" approach to configuration management, whereas Ansible uses a more "imperative" approach. For example, applying a Nix configuration is more-or-less guaranteed to be an idempotent operation, while this is not guaranteed at all using Ansible : many Ansible modules are not idempotent at all. This brings many useful features, for example the ability to rollback to a previous state, or more generally the ability to have some determinism in configuration management of complex systems. Nix and Docker can be combined together, I have many hosts where some services run in Docker containers, where the Dockerfile is defined in the Nix configuration itself, or generated by composing the upstream Dockerfile with my own configuration values.
rgoulter 5y ago
Loosely, I'd compare it to using Emacs or Vim instead of VSCode. You'll have a steeper learning curve, but it has power-user benefits.
ParetoOptimal 5y ago
> Can someone explain to me why I'd use this over say docker, ansible, or even a make file? Better reproducability by default. Docker containers usually have drift from `apt update` and that can let the "works on my machine creep in". You can avoid this in your own Docker containers, but you can't fix the whole ecosystem using that approach. The nix ecosystem avoids this drift and other sources of repriducability issues like the plague. If he is very popular Technologies with very common workflows, Nix might not seem worth it since the sharp edges from the lack of reproducibility have been filed down by brute force. You might find as soon as you need to do something slightly different, or need to get around a bug right now, you'll want Nix.

BoardsOfCanada 5y ago

I've tried for a couple of days now to set up nix for reproducible iOS builds at work and I'm close to tears. - Examples that just don't work. - Commands that run and no output is given, even though the text I'm following says it should output information I need. - Do I need nix-darwin? Well, the readme explains what it is: "Nix modules for darwin, /etc/nixos/configuration.nix for macOS." What? (Finally I found an answer at Stack overflow, and it seems I don't need it. Seems to be kind of NixOS on top of macOS) - Can't build with nix-build. After long time searching it seems like you're supposed to run nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' - shouldn't there be a simpler way for this common case? - An issue open since 2018 that the manuals simple example doesn't build: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 People chiming in years later that they only could build the example after reading the suggestions in that issue. - And now I can't start my nix-shell because it says there's a problem with SSL certificates. I'm giving up.

Shoue 5y ago
> - Can't build with nix-build. After long time searching it seems like you're supposed to run nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' - shouldn't there be a simpler way for this common case? This is because the default.nix you have is exporting a lambda that expects arguments to be saturated, `callPackage` does this for you automagically hence why you have to use it. Instead you probably want the nixpkgs import line _inside_ default.nix, either in a let-in binding or using the `?` operator to default a lambda argument to something, usually nixpkgs itself bound to a `pkgs` argument so you can use `pkgs`[0]. Even better, you can use Niv to pin nixpkgs to a specific nixpkgs commit so that it doesn't change as you update your system's nixpkgs channel with the `nix-channel` command because `<nixpkgs>` is special syntax referring to what's stored in your $NIX_PATH[1]. [0]: see the default argument section: https://nixos.wiki/wiki/Nix_Expression_Language https://nixos.wiki/wiki/Nix_Expression_Language [1]: https://nixos.org/guides/nix-pills/nix-search-paths.html https://nixos.org/guides/nix-pills/nix-search-paths.html
- pmarreck 5y ago
  You provided what is probably a logical explanation but didn't answer the question in the way he meant it (I think), which is: Addressing common use-cases should be a simple matter. Addressing complex use-cases should ALSO be a simple matter ideally, but is permitted to be a complex matter. Here we have a case where a common use-case is addressed by a complex-seeming solution (unless you are essentially "degreed" in Nix, apparently, and understand exactly why partial function application won't work here or whatever). Or are you saying he's actually doing it wrong and built the nix file wrong? I'm about to dive headfirst into this nix business and this is intimidating, lol

alduin32 5y ago

I've found the Nix language to be a really useful configuration language, even "outside" of the NixOS ecosystem. I reuse nixpkgs's module system, but to describe things that are used outside of the NixOS system (for example in an Ansible playbook). For example, I'm using it to describe a set of containers and services in my infrastructure, and it allows me to properly describe the interfaces between the different components of the infrastructure, using several modules : - a "base" module defines the options used for describing the services - one defines the services themselves - one handles the reverse proxy configuration for these services (for multiple frontends), as well as the SSL certificates and DNS zones - one handles the containers themselves (through Docker or LXD) - one handles the networking overlay - one handles the "shared services" (databases, caches, etc) Each of these modules is basically a function that takes the resulting configuration as argument, allowing it to reuse values defined by the other modules, and the configuration itself is the fixpoint of the composition of all of these functions. It all composes quite well, and the nixpkgs module system allows me to document the options provided by each module. I can even reuse some of the existing NixOS to create a web interface where other admins can search for configuration options and lookup their documentation. Some things are exported in JSON, some are used directly as NixOS modules, some things source the inventory for Ansible playbooks, etc. It allowed me to create a well-defined source of truth for a very heteregenous architecture, while preserving some of the existing workflows and tooling. It's not ideal of course : Nix itself is not typed, the nixpkgs module system provides some typing, but the integration is not perfect, and this makes error handling quite tedious. Also, the interpreter is quite slow, there is no documented way to embed it into your own program, and I

seqizz 5y ago

I'm using nixos for years, still couldn't grasp the language itself enough. I accepted that it's not for us, who are not familiar with functional programming. Like, what is even this: https://github.com/Ryunaq/dotfiles/blob/b132f79e2042d6ef75008d666ba12306ad21d427/flake.nix#L60-L66 https://github.com/Ryunaq/dotfiles/blob/b132f79e2042d6ef7500...

deleted 5y ago
[deleted]
chriswarbo 5y ago
It's a list of "overlays" (functions of two arguments, which return a key/value set). Overlays make it easy to overrides and replace things. If you prefer imperative programming, then think of it being used like this: const result = defaultNixpkgsSet; for (overlay in overlays) { // Merge the overlay's return value into the results value result := result.merge(overlay( result, // Give each overlay a reference to result result.copy() // Also give a snapshot of the contents so-far )) } return result; Consider an overlay something like this: function(result, snapshot) { return { maven = snapshot.maven.override({ jre = result.jre8; }) }; } Merging this into the 'result' will replace the 'maven' definition. That new definition is the same as the old one ('snapshot.maven'), but it will be using 'jre8' instead of the default. Two things to note: - We're using 'result.jre8', which will include any overrides made to 'jre8' (by other overlays, even those being applied after this one!) - We're using 'snapshot.maven', since using 'result.maven' would cause an infinite loop (since 'result.maven' depends on the output of this override!) In that link, they're calling their arguments 'final' and 'prev' instead of 'result' and 'snapshot', but the idea's the same. Most overlays call their arguments 'self' and 'super', but I avoided them in this explanation since those names have specific meanings in other languages (they're literally just variable names in Nix).
- zaphar 5y ago
  the result infinite loop issue is easily the most confusing part of nix. It works because nix is a lazy functional language. But I'm not particularly sold on that laziness being useful since it leads to awkward hacks like the two arguments to an overlay function. It has the one benefit of allowing you to not care about the order that overlays get called in. However it does that by giving your code magical come from semantics that make debugging a problem harder than it needs to be. I think the nix lazy semantics would actually have been better left out in favor of clearer dependency semantics. In a way the clearer dependency semantics of flakes are are driving the reason they are increasing in adoption so much. In essence they work around the problems introduced by overly clever usage of laziness in a nix package.

pmarreck 5y ago

Perfectly timed as I literally JUST started my (second ever?) Nixos attempt

michael_j_ward 5y ago

I spent like ~6 hours going through the first ~10 chapters of "how to learn nix" and the corresponding docs, and I've built up a decent model of how nix works under the hood but have no knowledge of how to do the things I want to do (reproducible dev environment per project) Hopefully that'll come in the next ~10 hours, or maybe I need to switch to one of these other learning resources - Tutorial motivated by accomplishing things [0] - Learn nix language syntax [1] - If video is more your thing [2] - The official "bite-sized guide" Nix Pills [3] [0] https://nix.dev/ https://nix.dev/ [1] https://nixcloud.io/tour https://nixcloud.io/tour [2] https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4... [3] https://nixos.org/guides/nix-pills/#nix-pills https://nixos.org/guides/nix-pills/#nix-pills

ianthehenry 5y ago
Since "How to Learn Nix" mirrors the (bonkers) presentation order from the official documentation, I am afraid to say that you will not learn how to do this until part 32, deep into the Nixpkgs manual. https://ianthehenry.com/posts/how-to-learn-nix/builders/ https://ianthehenry.com/posts/how-to-learn-nix/builders/ The Nix manual just doesn't talk about this. But the Nixpkgs manual will, eventually. Here's what it has to say: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-mkShell https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-mkShell That's it. Nix Pills does cover making development environments in chapter 10: https://nixos.org/guides/nix-pills/developing-with-nix-shell.html https://nixos.org/guides/nix-pills/developing-with-nix-shell... But Nix Pills is not really a "bite-sized guide" so much as a "let's motivate and invent the Nixpkgs genericBuilder infrastructure from scratch." So it doesn't really show you an example of how to write shell.nix files. Writing reproducible dev environments per project ("shell.nix files") is the main reason I use Nix. But Nix does not... make it very easy, out of the box. There are two more posts (separate from the documentation-reading sections) that will explain how to make this more ergonomic: - https://ianthehenry.com/posts/how-to-learn-nix/saving-your-shell/ https://ianthehenry.com/posts/how-to-learn-nix/saving-your-s... - https://ianthehenry.com/posts/how-to-learn-nix/nix-zshell/ https://ianthehenry.com/posts/how-to-learn-nix/nix-zshell/ (This is slightly unfair because if you're using Nix to build software, not just create a development environment, you get nix-shell for free. mkShell is sort of a special case of "I don't want the final result in the /nix/store; I just want you to put me in a shell with these packages installed." It's not a case that Nix optimizes very well for, even though it is my primary use case.) Finally, obligatory caveat that everything is completely different now in the "new" (unstable, flakes-based) Nix interface: https://ianthehenry.com/posts/how-to-learn-nix/nix-develop/ https://ianthehenry.com/posts/how-to-learn-nix/nix-develop/

pmarreck 5y ago

https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings did a pretty good Nix (and ZFS) sell. Of course, it was written by a guy who actually works on NixOS...

yoyohello13 5y ago

I see the appeal of Nix, but if your package manager requires a 50 part how-to learn series... At this point I don't really know if the juice is worth the squeeze.

chriswarbo 5y ago
I don't think of Nix as a package manager; I think of it like Make. The problem with Make (other than the awful syntax!) is that it's not composable. For example, GCC has a Makefile, with an "install" rule; yet my C project's Makefile can't use that as a dependency; e.g. hello: hello.o installGCC gcc -o hello hello.o hello.o: hello.c installGCC gcc -c hello.c # Pseudocode to import the 'install' rule (renaming as installGCC), from the # Makefile in GCC's source (depends on gccSource to fetch it) @import: gccSource import(gcc-10.1.0/Makefile, install -> installGCC) gccSource: wget 'http://mirror.0xem.ma/gnu/gcc/gcc-10.1.0/gcc-10.1.0.tar.gz' tar xzf gcc-10.1.0.tar.gz Nix solves that problem: we can write a rule (Nix calls them "derivations") which run wget/curl/git/whatever, and we can import files from the result. Nixpkgs (a big collection of definitions for Nix) takes this to its logical conclusion: C programs not only depend on their source, but also on the compiler, the shell used to run the commands, etc. In turn, the compiler depends on its source, and a shell, and a compiler (if it's bootstrapped). The shell depends on its source, and a compiler, and a shell to run the commands, etc. The downloader (usually curl) depends on its source, and a compiler, and a shell, etc. The recursion is cut-off by some "bootstrap binaries" (which the bootstrappable-builds project is trying to shrink even further http://bootstrappable.org http://bootstrappable.org ) With this "composability" problem solved, it turns out there's actually no need for "package managers" at all; or indeed for "installing" anything: each derivation just says what other derivations it depends on. Nix can act like a package manager if you want it to; e.g. its 'nix-env' command manages a "user profile" (a symlink at ~/.nix-profile, which point to the output of a derivation, which itself symlinks to the output of whatever derivations we want "installed"). NixOS works in a similar way, but with a system-wide /run/current-system symlink (plus a massive pile of options to configure things more easily). Hence the slight complexity of Nix (in fact, most of the complexity is in the libraries, like Nixpkgs) lets us do away with build tools (Make, Ninja, Ant, etc.), language package managers (maven, pip, cargo, npm, cabal, etc.), OS package managers (apt, yum, etc.), configuration managers (chef, ansible, puppet, etc.). Nix's "binary cache" mechanism also lets us do away with binary formats like rpm, dpkg, wheel, jar, etc. in a transparent manner (e.g. we can still patch sources, override compiler flags, etc.; we just get a cache-miss) Of course, that's the ideal. There's so much code written with Makefiles, pom.xml files, setup.py files, cargo.toml files, etc. that most Nix definitions just add those tools as dependencies, and let them do the building!

benreesman 5y ago

I think it's really important to have realistic expectations about Nix/NixOS when deciding how much effort to spend on it. It's ridiculously hard to get started. The online resources are simply inadequate: incorrect and/or out-of-date information is basically equally common as useful information. There isn't a good book you can get on Amazon. The "Learn" boards thing is full of "you're doing it wrong" bullshit. The Discord is so-so at best for getting help. For me personally it was somewhere between 1-3 months of being frustrated basically every day and I still want to throw things sometimes. It's basically clone `nixpkgs`, figure out how to get the REPL going, painstakingly reading the code of the stuff that does work, and pain. It says absolutely nothing about how smart/capable/motivated/senior someone is that a week or two in it's like "fuck this". The payoff is outrageous, but the barrier to entry is nowhere near something that can be called "acceptable", let alone "batteries included". I completely understand why a lot of people are all-but-hostile to it. I would budget a minimum of a highly frustrating month working with it every day to start to having the lightbulb moments, and frankly your use case needs to be pretty extreme in one way or another for that to be worth it. A lot of people don't have a friggin month to screw around with a fairly niche infrastructure if what they're doing now works for them. I really, really hope that at some point someone gets serious about making this fairly magical thing even remotely learnable, but right now it's a fucking mess.

nixpulvis 5y ago
I think this comment applies to nearly all technology today. If it doesn't have a `man` page, good `-h` notes, or a manual released with each version, I basically assume I'm going to have a hellish time Googling around for anything. This doesn't really solve the issue though, since a lot of manuals written are outdated by sources changes that were rushed and forgotten. We need to come to terms with the fact that the way we as programmers acquire information about our tools is in a dire need of help. Search indices are just not valid references for us. We should never have learned this method of learning in the first place, but it was easy and painless in the beginning. People need to just slow down a bit and become more methodical one thinks.
- benreesman 5y ago

nixpulvis 5y ago

Also read: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-packages https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... for what is in my opinion one of the most damning issues with Nix. Written by the same author if you didn't notice. In fact, reading over ianthehenry's blog is an interesting adventure in one mans experience learning this new tool.

aidenn0 5y ago
IMO, nix-env is a horrible, no-good, very-bad thing. It was also what the manual suggested using for installing packages when I learned nix. I have ditched it on all of my systems and have been so much happier... but there doesn't seem to be a single agreed upon replacement for it. I wrote my own, I'm sure others have well. It seems home-manager is popular, but it's certainly not even close to universally adopted and I've never gotten around to learning it myself. Maybe nix-env -irf does the Right Thing; certainly nobody pointed me at it when I was battling against the evil that is nix-env...
- nixpulvis 5y ago
  I disagree, I used it a number of times. It's practical. Sometimes you just want to install software the old-fashioned way. You can argue that isn't the right way to do things, and anyone running Nix will probably agree, but still I found myself wanting this and it served the purpose well enough. aidenn0, could you explain what `-irf` does and what it should do? I'm curious now, even though I don't currently use Nix.
  - aidenn0 5y ago
    > I disagree, I used it a number of times. It's practical. Sometimes you just want to install software the old-fashioned way. You can argue that isn't the right way to do things, and anyone running Nix will probably agree, but still I found myself wanting this and it served the purpose well enough. The problem is that it lulls you into thinking it serves the purpose well enough and then eventually things break. Then they get more broken. Then you can't figure out which thing you installed is breaking things. Then you finally do and can't figure out how to uninstall the thing that broke things. > aidenn0, could you explain what `-irf` does and what it should do? I'm curious now, even though I don't currently use Nix. I'm pretty sure it sets up the environment from a file; I found it one link away from the link in the comment I replied to here[1] 1: https://ianthehenry.com/posts/how-to-learn-nix/declarative-user-environment/ https://ianthehenry.com/posts/how-to-learn-nix/declarative-u...

timwis 5y ago

Love the idea of a blog post like this. I tried something very similar a couple weeks ago on a c++ project, both in hopes it might lead to an improved user experience, and also for others struggling to figure it out. https://github.com/valhalla/valhalla/discussions/3540 https://github.com/valhalla/valhalla/discussions/3540

mamoriamohit 5y ago

> Or you just memorize the “right way to do it,” and every time you type it, a part of you wonders why, until eventually your mind crystallizes around this idea that Nix is confusing and weird and too hard for you to figure out. This stands true for most of the things in universe for most of the people.

bluefirebrand 5y ago

My only experience with Nix was one job, where we hired a new guy who had just done his PHD in Computer Science but never written production code. Someone on the team was mentioning that our build/deploy pipeline was a pain in the butt, and it would really be nice to have a proper CI process implemented. PHD spoke up saying he could help with that, and then spent the next three months wrestling with Nix. I left the company before I saw how long it actually took him, though. I saw enough to realize it would likely never be worth my time to use. Sorry Nix.