Use upcoming 'pkgBin' feature from nixpkgs to set entrypoints

[tazjin]

Suggested by @zimbatm:

Nixery should use information about the primary binary of a derivation to set the entrypoint of a built image. This information is not currently easily queryable from Nix, but NixOS/nixpkgs#67392 is working towards that.

The main question on the Nixery side of things is which derivation should be picked for this.

Given an image like shell/nginx/nmap/stunnel we'd be faced with two services that could potentially be intended to serve as long-running processes. Which one would be appropriate?

My gut feeling is that the first non-meta package (i.e. nginx in this case) should be chosen, as people are likely to "pile on" stuff like debugging tools at the end of the image.

[jpetazzo]

FWIW, I've been experimenting with this a little bit (but, since I don't know Nix very well, the way I did it was extremely naive: just use the name of the first package as the entrypoint; so in an image like foo/bar/baz the entrypoint is just foo). I found that it "works" but that it's actually not very helpful, because:

• for servers, it's very rare that we can just run the server binary as-is without adding more options, or a config file;
• for tools used from a shell (e.g. "docker run -ti nixery.dev/shell/stuff/morestuff") I found that it was easier to give a shell by default;
• for tools used in CI pipelines or initContainers, I always need to provide a script, or extra arguents anyway.

So at the end of the day, I found that setting a smarter entrypoint (or cmd) wouldn't really help me much (that's why I settled on the simpler option of setting CMD to "bash" when the "shell" metapackage is used, because I found that one helpful in practice).

That's just an observation on my personal workflow (and seeing some students use Nixery images, too) though; so I'd love to see what others think!