Package as a Nix flake

[charles-dyfis-net]

(This was assembled for my own use; no offense will be taken if it's not desired upstream).

Nix is build framework built on top of a pure functional language with immutable values at its core. These pure functions composed to generate build steps which -- while inherently impure -- are run in aggressively sandboxed environments to get as close to purity as is reasonably achievable.

• Two systems building the same Nix derivation are guaranteed to be using the same compiler (with the compiler itself built from the same inputs using the same build steps and the same dependencies made available to the sandbox), the same dependencies (with identical hashes: network access is only allowed to build steps when they declare their outputs, and those outputs are checked against the declared hashes), and the same build steps.
• Nix supports several operating systems, including MacOS, most Linux distributions, and a Linux distro build specifically on top of it (NixOS). Being packaged with Nix lets users across several different environments build your software in a manner that tries very hard to hide the differences between those environments, dramatically reducing the room for "works on my machine" problems, or users whose issues are difficult to reproduce.
• One can run software packaged with Nix without needing to globally install that software or its dependencies; everything lives in a hash-addressed location that doesn't conflict with any other software. If someone invokes nix run github:charles-dyfis-net/clj-jq/ec26ae8768bee665ff27d5a869656f8a31bccc54#jq-cli, this will (if they're on MacOS arm64, and I haven't amended this PR in a way that makes that hash unavailable) compile and run a native executable /nix/store/wwv070qh67l41yn30vzkqvnprz4amdlw-clj-jq-1.2.1-SNAPSHOT/bin/clj-jq, built by a graalvm version at /nix/store/07wffji6n1sbka4cvlwkyzp3fr68d03m-graalvm17-ce-22.3.0, which is itself compiled against a specific hashed version of the tools in its dependency chain (though in practice, it's downloaded from a public binary cache unless the user has chosen not to trust same). None of these executables are installed in the PATH or otherwise modify or are modified by behavior of other installed software on the system.
• Unlike the dependency info tracked by pom.xml and similar tools, a lockfile to be used by nix must contain hash of content downloaded (as only build steps that know the hash of their outputs have network access). Consequently, builds performed by Nix can detect upstream dependencies being changed even when the version number is not updated.

[dainiusjocas]

Thanks for your contribution!

I have no experience with Nix, but it would be good to learn about it.