HN Theater @HNTheaterMonth

A few of these problems are fixed with flakes - namely the dramatically improved composability. It becomes much simpler to understand how to use something when you are able to work on it in isolation. With the previous mono-repo nixpkgs assumption, you were basically required to not only learn nix-lang, but also nixpkgs and the nixpkgs workflow making it much harder to grasp the fundamentals.

With flakes, it is now significantly easier to create an standalone package or module for your specific needs since you import it just like nixpkgs. It also means that software doesn't have to be part of nixpkgs to be usable on the system - if a git repo has a flake it's just a matter of adding it as an input. Flakes represent such a massive improvement to the way that you interact with nix, I sincerely hope they become the default here soon. In the meantime, it is well worth your effort to learn them even if they aren't 'required' yet.

Unfortunately all of this is contingent on being able to grok the language in the first place which is where the documentation really falters. The nix pills talk about the basics of the language but it is very difficult to make anything useful without importing some libraries (i.e. nixpkgs) - and these libraries are not very well documented. I am aware of a documentation team being formed to help address this but it still remains the number one issue with nix, especially for newcomers. The unfortunate thing is that there are so many moving parts that it will take a considerable effort to explain the entire ecosystem without being overwhelming but still providing enough intuition for newcomers to get things done with Nix.

If anyone is interested, a recent SoN talk was given about efforts to improve the documentation. It touches on many of the things I bought up here: https://www.youtube.com/watch?v=WFRQvkfPoDI

⬐ zamalek

I really hope to see a lot of packages move out of nixpkgs, only to be re-imported as flakes. There are currently 3.9k pull requests for nixpkgs; the current model really isn't working.

⬐ zimbatm

Look at the ratio instead: 4k open vs 162k closed. Or 4k open vs 80k+ packages.

If we split things up, there will be less open PRs per project of course. But I doubt the ratio will be much better. It will actually increase the number of PRs as large scale refactors will be multiplied by the number of repositories.

⬐ dd_

I don't know if packages should necessarily be moved out of nixpkgs since I doubt most people who don't use nix would want to maintain flake.nix in their project, nor would users want to have 30+ flakes in their inputs. However, I can see a good case for separating the package definitions from the nixos modules and the stdlib (mkDerivation, stdenv, etc). Maybe there could be a flake for each.

As for keeping up with PRs and other responsibilities, that seems to be one of the stated goals of the this new Nix Team. I guess we'll see how they intend to handle this soon.