Not an expert on Nix, but it's not so much that Nix has problems (though I'm sure it does, my initial research suggested it's not quite there yet for Python packages) but that there other things you need to get right.
> though I'm sure it does, my initial research suggested it's not quite there yet for Python packages)
Can you expand on what's missing? I've successfully used nix to cross-compile a pretty substantial python application (+ native extensions, hence the cross compilation), for embedded purposes, and it pretty much worked out of the box. Adding extra dependencies was straightforwards.
I think you can use pypi2nix for pinned dependencies, and you can run it periodically for security updates.
Like I said, it was very preliminary research... I reached the bit where pypi2nix did "nix-env -if https://github.com/garbas/pypi2nix/tarball/master" and wasn't super happy about the implications of "just use master" for production readiness.
If it works, though, that's great!
The more general point though is that in my experience no tool is perfect, or completely done, or without problems. E.g. the cited https://grahamc.com/blog/nix-and-layered-docker-images suggests you need to spend some time manually thinking about how to create layers for caching? Again, very preliminary research—I know people are using it, I'm just skeptical it's a magic bullet because nothing tends to be a magic bullet.
> The more general point though is that in my experience no tool is perfect, or completely done, or without problems
I agree. I had to do a lot to cajole nix to cross-compile some python extensions.
However, I've done this before manually and using various build systems, and the advantage of Nix is that (1) equivalent builds are cached (reducing compile time), (2) the dependency graph is assured to be clean, (3) the entire state is pure (I can send my nix expressions to a hydra and be guaranteed a successful build), and (4) reuse -- once I modified the higher-level python combinators to build cross extensions, I can add new modules easily.
Regarding layering, it used to be a completely manual process (just like with Dockerfiles), but the point of the blog post was that you can now use `buildLayeredImage` and correct layering will Just Happen.
For example:
1. Signal handling (only one bit of https://hynek.me/articles/docker-signals/ is Dockerfile specific, the rest still applies.)
2. Configuring servers to run correctly in Docker environments (e.g. Gunicorn is broken by default, and some of these issues go beyond Gunicorn: https://pythonspeed.com/articles/gunicorn-in-docker/).
3. Not running as root, and dropping capabilities.
4. Building pinned dependencies for Python that you can feed to Nix.
5. Having processes (human and automated) in place to ensure security updates happen.
6. Knowing how to write shell scripts that aren't completely broken (either by not writing them at all and using better language, or by using bash strict mode: http://redsymbol.net/articles/unofficial-bash-strict-mode/)
etc.