Writing convenient unix utilities in nix

I have a conundrum! I would really appreciate some words of wisdom from nix gurus.

I am writing some data-analysis utilities that are glued together with nix and I am wondering about the best way to provide simple user-interfaces for them (e.g. from the unix shell.)

For example, I have a utility that processes profiler data files to produce textual reports (similar to perf report), and the current user-interface is like this:

$ nix-build -E '(import studio/tools/vmprofiler {}).analyze_dir(/var/run/snabb/12345/engine/vmprofile)'

but that's quite verbose and users would probably much prefer a usage like:

$ vmprofiler -i /var/run/snabb/12345/engine/vmprofile -o .

and now I am wondering how to at least partially bridge that gap so that the command-line interface won't be a barrier to adoption of the tools.

I suppose that I have at least three potential ways to make a shell script wrapper:

• Make it use the #!nix-shell shebang to run the tools directly with the right env.
• Make it call nix-build directly in the script (wrapper to current usage.)
• Make it into a nix package that is installed with nix-env.

I am somewhat drawn to calling nix-build because I like the idea of copying the input data into the nix store. These tools can potentially operate on large amounts of data that requires expensive preprocessing and I'd love for nix to transparently cache this intermediate processing. So while I want to have a convenient user-interface I am also happy to have nix as a runtime dependency and to use it as effectively as possible.

Does anybody see the dilemma and have an idea for how to sort it out?

Here are a couple of the scripts I am talking about:

• timeliner/default.nix
• vmprofiler/default.nix

"The problem" is to provide command-line usage instructions that won't make people go "ugh" and also won't give up nice benefits of deep nix integration.

Start by reviewing tools/timeliner/default.nix and tools/vmprofiler/default.nix, then compare the proposed #!nix-shell, nix-build wrapper, and nix-env approaches. The issue does not define a chosen approach or a documentation target, so a contributor would need maintainer guidance before there is a clear done condition.