Whenever I publish something about my Python Docker workflows, I invariably get challenged about whether it makes sense to use virtual environments in Docker containers. As always, it’s a trade-off, and I err on the side of standards and predictability.
deleted by creator
That’s true, but also misleading.
OCI image is like having an jpeg image. While Dockerfile is like the text prompt you write to ChatGPT to generate the image.
Yes every time you look at the jpeg, it is the same exact image, but that’s kind of obvious, the real problem is if you try the text query to ChatGPT you will get something slightly different every time.
Nix brings a true reproducibility. So in this analogy the same prompt brings the exact same image. This allows you to check on that prompt in your source control and if you mess up something there’s always a way back.
This is something docker promised, but never delivered.
It should not, but artifacts never had problem with mutating before we had docker. If you generate an rpm package and store it in an artifactory it always was the same exact package (unless someone overwrote it, lol)
But that’s basically the problem docker claimed to fix. This is also the problem that you frequently encounter with a pipeline that worked fine one day suddenly stopped working next day, because something that your Dockerfile referenced changed (maybe a new image was updated that broke something, you can lock things to specific hashes, but you need to be very conscious about that and in the wild I never seen anyone really doing it).
It is not. Hashes are and lock files are built-in and Nix uses them by default.
If for example I use a flake, the flake.lock will hold the exact version of nixpkgs (package repo) in time. That happens without any additional effort. The poetry2nix converts poetry.lock file to nix packages that are once again locked in time, and that also happens behind the scenes.
The result is that all dependencies (python dependencies - from poetry.lock as well as the rest of the system (python, c libraries etc) - from flake.lock are all locked and in my repo. So everything is repeatable without effort on my side.
To repeat that with Dockerfile is much more challenging.
If you get your app build with Nix. The whole thing, including all of app’s dependencies are explicitly referenced so you can wrap it into a docker, an rpm file, OS image etc.
It’s controversial, but IMO nix is actually easier than what we are doing now. I think the problem is that it is a massive paradigm shift and what most people know what to do with existing technologies will generally be not useful, so you have to relearn everything.
But IMO it pays off. For example when starting a new project I can package the whole thing in 5 minutes. poetry2nix translates the project and it’s dependencies into nix packages and then since nix understands dependencies for my project it can package it automatically.
You make a good point in that Docker promised to make dev environments reproducible so that everyone on the team would have the same environment. They even succeeded in that, but either intentionally or accidentally omitted reproducibility over time due to the introduction of non-locked dependencies.
deleted by creator
You use them, make sure they are always pristine and cleaned after use, don’t have network connectivity and other things that could affect the build.
Or you could use Nix which builds everything this way.
Notice that you mentioned additional systems to achieve that, you wouldn’t need them if docker was truly providing it.
But that’s the whole point. A developer wants spec file to ALWAYS generate the same artifact. And most devs even believe that and get frustrated when it doesn’t (like in your example).
Nix basically solves that. It even removes the need for tools like artifactory, because there’s no longer need for it. The code fully defines the final binary. Of course you don’t want to rebuild everything every time, so a cache is introduced.
Before you say that it is just renaming artifactory. It really isn’t. It actually works like a cache. I can remove any piece of it, and the missing pieces will be rebuild if they are needed. It is also used by the builder, so it doesn’t repeat itself. I especially like it when working on feature branch and it completes the code. I eventually merge it, and if my merge did not modify code it won’t waste time rebuilding the same thing.