| > Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime. Yet Docker conflates the two, introducing all sorts of unnecessary friction all over the place. But Docker in fact doesn't have compiletime dependencies, it needs you to specify runtime deps only. If you want to build something in Docker, you use two-stage builds and the runtime deps of the first stage become your compiletime deps. > This is why something as simple as getting more than one process to work with each other on Docker is such an overcomplicated mess I don't get this, why is it considered an overcomplicated mess? If you want to run several processes in one container, you just launch it with a lightweight process manager, if you want to run it in separate containers -- well, that's even easier, just launch separate containers and configure the communication between them with a network. > Nix gets this right with better design and composable packages Nix actually implements it worse than Docker in some sense. Particularly, the exact problem that you described: > Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime is not solved in Nix, runtime deps must be a subset of compiletime deps. > that's neither composable nor customizable Compositionality is a completely different issue on which I do have problems with Docker. DAG-oriented environment building is strictly better than inheritance-oriented, but that's all orthogonal with compiletime-runtime separation. |