docker-compose seems necessary only because you have your "official postgres dockerfile" and your self-built "web app dockerfile" (and maybe other things like an ElasticSearch dockerfile)
Docker files seem necessary only because... well put it this way, think of a Docker image as "the cached result of a build that just so happened to succeed even though it was entirely likely not to, because Docker builds are NOT deterministic."
Now enter Nix, where builds are more or less guaranteed to work deterministically. You don't need to cache them into an "image" (well, the artifacts do get cached locally and online at places like https://www.cachix.org/), and the only reason they can do that is because they too are deterministically guaranteed to succeed, more or less), which means you can just include any and all services you need. (Unless they need to run as separate machines/VM's... in which case I suppose you just manage 2 nix files, but yes, "composing" in that case is not really fleshed out as a thing in Nix, to my knowledge)
except you cant deploy Nix files, and even if you could, better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
> better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
lol, "tell me you never used Nix without telling me you never used Nix" because it literally guarantees that, each project is a pure environment with no outside influences. THAT IS LITERALLY ITS ENTIRE PURPOSE OF EXISTENCE lolol
I absolutely guarantee you that you will have more reproducible builds with Nix than with Docker. I know, because I've worked with both of them for months on end, and I've noticed that it pains me to work with Docker more than it pains me to work with Nix (hey, it's not perfect either, but perfect is the enemy of good in this case)
First you are tightly coupling your CI to your developers machine, that in itself is already a pretty bad idea. Second, if one employee wants to install htop on their machine, then every employee will have to install it, this can quickly become a problem when you have 500+ developers. Third, I think you missed the first part on the second quote, you are FORCING every developer to not only use linux but also to use one distribution that is pretty niche.
> First you are tightly coupling your CI to your developers machine
It's not like you can't configure builds differently based on an ENV variable, which is exactly what most build tools already do.
> Second, if one employee wants to install htop on their machine, then every employee will have to install it
There's actually a way to install things on the fly on first use. That way, if you never use it, it will never install. If you use it more than once, it will use the locally-cached version. Next?
> this can quickly become a problem when you have 500+ developers.
Nope. Already answered. Plus, you can allow some things into the "pure" environment if you wish. Harmless things like btop or htop, for example.
> Third, I think you missed the first part on the second quote, you are FORCING every developer
What part of "everyone has to use slow-ass non-deterministically-building Docker" is NOT "FORCING" every developer to use something? LOLOL. Plus, on Macs (which USED to be my preferred dev machine) it's slow as fuck, which is why I had to switch to a linux laptop anyway, which is why I said "fuck this" and installed NixOS and went to town instead.
> to not only use linux but also to use one distribution that is pretty niche.
First of all, wow, you are naïve. No good thing DID NOT start out "niche". Literally every technology I've gotten into except for ASP.CRAP was "niche" when I got into it- from Ruby, to Postgres, to Elixir, to Jquery (at the time)... Do not judge things based on their popularity because that's the Appeal to Popularity fallacy. Judge things based on their promise, young padawan. And Nix... promises much.
On systems that have the same containerization feature that Docker requires, i.e., Linux systems with recent kernels, you can use nix-bundle¹ or the flakes-based experimental command inspired by it, `nix bundle`² to generate an all-in-one binary that you can run without installing Nix on the target.
Docker files seem necessary only because... well put it this way, think of a Docker image as "the cached result of a build that just so happened to succeed even though it was entirely likely not to, because Docker builds are NOT deterministic."
Now enter Nix, where builds are more or less guaranteed to work deterministically. You don't need to cache them into an "image" (well, the artifacts do get cached locally and online at places like https://www.cachix.org/), and the only reason they can do that is because they too are deterministically guaranteed to succeed, more or less), which means you can just include any and all services you need. (Unless they need to run as separate machines/VM's... in which case I suppose you just manage 2 nix files, but yes, "composing" in that case is not really fleshed out as a thing in Nix, to my knowledge)