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

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.

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.

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.

I generally agree that the documentation is a problem. A lot of the code is commented, so if you can find a package in nixpkgs that is using the same language, you can usually do some copypaste, somehow find the function definition it's referencing, and then it's not so hard to make the changes to package your new package. But "somehow find the function definition it's referencing" is not always as easy as it sounds... I think it's the only way to learn though. The documentation just isn't up to the level it needs to be to be self-sufficient.

As for flakes, they're not that big a change. There's some entry point which you have to learn about - a special file (flake.nix) that defines inputs and outputs according to some predefined structure. But the output leafs are just normal nix code - it's just that there's some builtins that can't be used because they do side effects at runtime. But that's less important than it sounds, because if you're using nixpkgs (as a library/input or as a source for copypasting) then it's flake-safe.

This is generally true, but I have yet to successfully make a nix overlay for any haskell package not already in nixpkgs. I can't make heads-nor-tails of how the haskell packaging works, other than forking nixpkgs and rerunning the scripts that generate the packages from cabal.

Try this:

https://github.com/Gabriella439/haskell-nix

and for nix in general this recent tutorial:

https://nix.dev/tutorials/nix-language

I like to summarise my experience (which resembles yours) as "nix is 95% wonderful, 5% very painful".

> the code replaces my notes entirely.

I think this ends up being one of the key selling points for Nix for developer machines.

> like software packaged as Wine bottles

I always wondered why there are no wine packages using nix. Sure, it is likely not legal, but I would absolutely love to have an MS office package that mandates a specific hashed file (that I can torrent and add to the nix store - this way I don’t even risk viruses), and the install itself is deterministically done (perhaps with some headless GUI clicking here and there).

Windows application installers generally are just binary blobs that can do as they please, so just pinning an installer will not imply that the resulting installation will be deterministic - a lot of installers by design change the global state of the system and download stuff during the installation process. If you want packaged on Windows, try choco.

Edit: fixing autocorrect typos.

For what it's worth most of the "packages" on chocolatey are just instructions for downloading those same installers and executing them in their respective silent modes. No one is repackaging those apps except for maybe some of the ones marked as "portable".

You are right in the first approximation, windows application installers can do whatever they want. However, many applications work already if you extract the files from the installer and put them into the appropriate directories, which you can make a deterministic process. There are tools for this, e.g. msiextract.

Should work for portable apps, or anything else that's distributed as an archive that can be directly extracted and work

(So AIUI a tiny fraction of the available software. Still, it's not nothing.)

You could probably wrap Scoop packages into a Wine environment with Nix fairly easily, since all the packages in their main repos are well-behaved, portable, and install non-interactively.

(You probably mean Choco, short for Chocolatey, by the way, just in case anyone gets confused.)