[siraben]

It's not so bad actually. To add a new package there's only two files you have to touch, add a new default.nix somewhere in the pkgs/ tree and add your package to pkgs/top-level/all-packages.nix. Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.

[throwaway894345]

This comment reminds me of the "How to draw an owl" meme:

1. Draw some ovals

2. Draw the rest of the effing owl

Yes, you only have to write your Nix expression code in a couple of files; of course, the issue is "how to write that Nix expression code correctly".

> Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.

This is exactly the fallacy I addressed in my comment--Nixpkgs is a really brutal reference for a variety of reasons. Let's say you're building a Python project--first of all, good luck finding a good reference package in nixpkgs if you don't already know where the Python packages are. Secondly, the general scheme seems to be "import nothing, write some function that takes dependencies as arguments", which means you'll have no import statements pointing you to the source files for the dependencies. Further, because nixpkgs doesn't believe in docstrings or static types, you'll have nothing that helps you infer the shape of the thing you're searching for or otherwise provide you with reliable grep criteria. You'll need to grep for the call site for your function to determine what gets passed in, and that thing might be the result of calling some other function with its own args, so you end up recursing through this process for the whole dependency tree. It's needlessly tedious, and this example is just the tip of the painful iceberg.

[lakecresva]

This was exactly my experience. They have manuals that are very comprehensive reference texts, but complete lack of structure (no types, no docstrings, no enforced conventions/standards, extremely poor discoverability) makes it a nightmare in practice.

[throwaway894345]

Right, most recently I was looking at the reference for buildGoModule, which produces two derivations--one for pulling the dependencies (e.g., go mod download) and another for building the package. Basically the idea is to avoid re-downloading dependencies if only the package's source code has changed. Anyway, buildGoModule takes a `goModHash` field (or something like that, anyway) which is supposed to be the hash of the dependencies derivation; however, it completely omits any information about how to actually get that hash (and if you think you can just build the package and get the correct hash from the error message, you're mistaken). Googling around a bit online you'll find that you can use nix-prefetch, but it appears to only work on Linux. Note that this quirk is particular to Go, but this is the same sort of thing that you run into all the time in the Nix ecosystem.

[microtonal]

and if you think you can just build the package and get the correct hash from the error message, you're mistaken

Actually, you can. In any place a SHA256 hash is required, you can put *lib.fakeSha256" (which is an all-zeros hash) and the build will fail and Nix will tell you what the correct hash is.

[siraben]

Yeah, better documentation is sorely needed in Nix, heck, I can't even look up docstrings in the repl (by default, there is nix-doc[0]. I asked around on IRC about a typechecker for Nix, and people refer me to the Dhall[1] and Nickel[2] projects. Looks like some preliminary work on type checking[3] has been done.

[0] https://github.com/lf-/nix-doc

[1] https://dhall-lang.org/

[2] https://github.com/tweag/nickel

[3] https://www.tweag.io/blog/2017-05-23-typing-nix/

[soraminazuki]

The documentation and language syntax is order of magnitudes better than RPM, though. With RPM, even stuff like commenting out code doesn't work as expected due to parsing quirks and good luck trying to figure out why.