Hacker News

Nixpkgs for the frontend impaired(fzakaria.com)

89 points by surprisetalk 3 days ago | 19 comments

> Ask nixpkgs a question in a loop. Interrogate and explore nixpkgs in a REPL

  nix repl --expr 'builtins.getFlake "github:NixOS/nixpkgs/nixos-unstable"'

  nix-repl> builtins.filter (name: lib.licenses."${name}" ? spdxId && lib.strings.hasPrefix "GPL" lib.licenses."${name}".spdxId) (builtins.attrNames lib.licenses)
  [
    "gpl1Only"
    "gpl1Plus"
    "gpl2"
    "gpl2Only"
    "gpl2Plus"
    "gpl3"
    "gpl3Only"
    "gpl3Plus"
  ]

[–] OskarS 15 hours ago

Yes, you're absolutely right, but you're also illustrating the author's broader point a little bit. For someone not very deeply familiar with Nix (the language), that is a very difficult one-liner to parse. You have to be pretty hard-core nix-pilled to understand what that one is doing just reading it straight-on (my NAS is using NixOS, so I've written some amount of Nix). On the other hand, the TypeScript code the author provides is reasonably straight-forward, you don't have to be particularly familiar with either TypeScript or Nix to understand what it is doing.

You're correct in that the article is wrong in saying you can't use a nix repl this way, but I took the broader point of it to be "Nix-the-language gets in the way of the Nix-the-model". Which is something that I personally agree with 100% and I think the article illustrates beautifully.

[–] alexandrutocar 18 hours ago

Exactly my thoughts. You can even go as far as `nix eval .#<attr> --json --apply <expr>` to transform whatever your flake outputs list into your desired format and then presenting it as JSON. Then you can consume the JSON and process it with a language of your choice. Or you can extend the standard library with your own primitives, types and tricks and do whatever you want to do in Nix. The switch to other language is worth only if processing that you are doing becomes too slow or too clunky in Nix - both are subjective, so I personally do the processing in Nix and export it only if I want AI in the loop e.g. giving my packages and services as context to siff through changelogs of flake updates to make summaries with information relevant to my systems.

[–] tensegrist 16 hours ago

in my over a decade of using nix i have never really managed to get into using the repl because every time i have it's been … weird in some way or another

[–] skavi 21 hours ago

aren’t there also nix lsps

[–] tom_alexander 18 hours ago

Yep! Personally I use nixd but there are multiple nix lsps. There are definitely places where nixd stops helping due to nix being a dynamically-typed language. For example, when writing functions it doesn't know what the types of any of the parameters are because they could be literally anything. That being said, the example from the screenshot of typing `pkgs.neo` and getting a list of completions for package names absolutely works with nixd.

What's weird is Farid absolutely knows about both nixd and `nix repl` but he didn't mention either of them or compare, instead making it sound like nix doesn't have a repl or a language server.

[–] easygenes 1 day ago

Please at least add "(Nix transpliled to typescript)" to the title so it's clear what we get.

[–] gavinray 16 hours ago

  > "Nix is lazy, so the emitted code wraps an expression in nix.thunk(() => ...)"

Why not use Generator functions rather than manually wrapping everything?

On-demand value materialization is what Generators are for

[–] lorecoeur 1 day ago

Funnily enough, it might very well be a morale failure. Just not a moral one.

[–] boredatoms 1 day ago

Is there a nix-language learning book out there? Last I looked it was pretty difficult to get learning material

[–] isityettime 23 hours ago

Not a book (you don't really need a whole book for such a small language!), but this is the classic resource: https://nixcloud.io/tour/

Then the things you need to learn in order to read and understand most Nix code is just the stdlib, which is most convenient to browse here: https://noogle.dev/

Beyond that, it's all just conventions that are covered well by reference material. So those two are all you need in order to find your footing when it comes to the Nix language.

(For a tutorial overview of the whole ecosystem, nix.dev is the best entrypoint. For the build system or an introduction to some of the basic "internals", you want The Nix Pills. And in general, the best thing of all to read when it comes to Nix is Nixpkgs itself. :)

[–] john_minsk 1 hour ago

I'm already suspicious:

   Shortcuts
   next page: ctrl + j
   prev page: ctrl + k

P.S. thank you for links.

[–] YoshiRulz 1 hour ago

Another option: https://zero-to-nix.com

[–] tomodachi94 1 day ago

nix.dev is generally pretty solid. Check out their tutorial for the Nix lang: https://nix.dev/tutorials/nix-language

[–] azeirah 23 hours ago

Fzakaria has whatever the opposite is of AI psychosis. He's in an AI flow.

[–] __MatrixMan__ 1 day ago

[–] aitchnyu 21 hours ago

Umm, does a Nixfile have a "grammar" of a 140000+ records and 232000 attributes from its individual packages? Can a lightweight text editor underline an error?

[–] viraptor 20 hours ago

It doesn't have to be specific attributes. It's just map(string, derivation) for the package list, however you language expresses that.

Similar to how JS has x["a"]==x.a, they're attributes.

[–] peter_d_sherman 1 day ago

Excellent article!

Heck, not just an excellent article, an exceptional one!

This is why I read HN -- to find articles like this one!

The basic problem:

Everybody loves Software! Software, specifically having a huge breadth and variety for a given platform is the key to that platform's success! (Just ask Bill Gates of Microsoft that, about Windows!) Well a lot of Open Source software is on GitHub, but one problem is (or rather was!) that it needed to get built for a whole bunch of platforms... Simple right? Well, not so much for the average user who is not a programmer when there are numerous types of CPU (x86, ARM, RISC-V, etc., etc.), numerous OS platforms, numerous compilers and compiler versions, and (usually) other dependencies on specific versions of other Open Source software packages...

So who could solve this chaotic "wild west" of exponential build combinations?

Well, historically, GNU autotools (aclocal, autoconf, autoheader, automake, autoreconf, autoscan, gnu m4, libtool, etc., which created files such as: aclocal.m4, config.h, config.h.in, config.log, config.status, configure, Makefile, Makefile.in, etc.) tried to solve this problem, and for the most part did so -- but usually only for users who were familiar with using Unix/Linux command-line tools and usually only for GNU compilers, and build processes which had dependencies on other projects or libraries could break rather spectacularly if the exact correct version of those projects or libraries that the base software was dependent on was not known, or not selected correctly.

What was needed was something more generic, and yet more precise.

Enter Eelco Dolstra, and his Ph.D. thesis "The Purely Functional Software Deployment Model": https://edolstra.github.io/pubs/phd-thesis.pdf

Which is the basis for the Nix functional programming language, NixPkgs and NixOS.

Basically, all problems in software deployment (i.e., configuring and building software correctly from source) could be solved if there was the following:

Immutability in Storage: Once a software component is built, it is stored in a centralized location (the Nix Store, typically /nix/store) and marked as strictly read-only. Components are never modified in place.

Purity of the Build Process: Build actions are treated as mathematical functions. A build process is strictly isolated and hermetic—it is stripped of access to external environment variables or network resources, ensuring that the exact same inputs will always produce the exact same cryptographic output.

Well, turns out Eelco Dolstra and Nix / NixOS were right!

Why? Because now there are over 140,000 Open Source software packages in NixPkgs, i.e., installable by the Nix Package Manager. That's more than any other Linux package collection. And the breadth of combinations of CPU's, Platforms, OS'es, etc., far surpasses the build options of any other Linux distro's package collection!

But that's the next problem, and that's the problem this article so brilliantly addresses -- which is, if all of that software ecosystem, all of those build scripts are ultimately tied to Nix language, and the Nix language is hard to understand / hard to modify for newcomers to it, then how to unbind that entire software ecosystem from the Nix language?

And the answer (or at least one answer!) is what this article author suggests, which is "hey, let's convert the Nix language to Typescript"!

And this is (one great!) solution to the following problem:

>"Anyone who wants to explore the store-model space from a different direction, a new language, a new evaluator, a new editor experience, must then start from zero packages. This is the graveyard where other reimplementations or forks of Nix go to die."

Well not anymore!

Anyway, a truly brilliant article!