There are a lot of small annoyances that people frequently run into, in both Nix and nixpkgs. Annoyances that are often small enough that they don’t get filed as bugs but only complained about off-handedly, or that are symptomatic of deeper design / project management issues, and that are therefore not possible to deal with as an isolated issue.
So, let’s compile a thread of such issues, to get a better idea of what kinds of UX papercuts we still have!
To contribute, simply post the things that you run into that you were annoyed or confused by. The descriptions don’t have to be extensive like an issue you’d file on a repository (the point is to have a low barrier for reporting them!), they only need to be detailed enough that other people can understand what it’s referring to.
If there’s already an issue thread about your annoyance, feel free to include a link to it as well. Issues can be about any part of the Nix ecosystem.
I’ll start with a few:
builtinsinclude bit-wise operations for
bitXor- but not for
bitNot, for which you inexplicably need a nixpkgs library function.
nixpkgs.libre-exports the built-ins
div(divide)… but not
libonly seems to include
foldvariants that explicitly take an initial accumulator, not variants that can take the first/last item of the list as the initial value. This makes things like
lib.maxunnecessarily painful to apply to an entire list.
- The various Nix* manuals are unpleasant to search through, because they are giant pages and so any external search engines (eg. Google) won’t jump to the correct part of the documentation. Every attempt to find something of which the exact naming used in the manual is unclear, therefore involves two search operations; one in Google, and then another on the manual page to find the right section.
- The builtins in the Nix manual are listed alphabetically, rather than in a more sensible order like category or frequency of use.
- The documentation for
builtins.toJSONdoes not specify explicitly whether a derivation will be built when it is stringified, or whether it will merely be converted to a string of its output path without actually triggering a build.
- The purpose of
nixpkgs.libis totally unclear; it seems incredibly specific, is only used in a single place in all of nixpkgs, and seems entirely too complex to live in a file named
- The purpose of the URL literal syntax in the Nix language is unclear, and it actually doesn’t seem to have a purpose at all (compared to a normal string literal). This frequently confuses people. (issue)