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.
The team I’m part of wants to ditch Nix in favour of just about anything, because no one wants to maintain Nix and everyone sees it as just source of problems :(
I agree that it was complicated to learn Nix for me, too, but now I see benefits in it but I can’t make them change their mind and tired of trying. Nix could’ve been much easier to advocate for if the language itself wasn’t this esoteric
I see that too. Despite what most people say they aren’t truly interested in learning new things (at least things that would force them out of their comfort zones).
I mean if team tries to move out then there’s not much one can do.
Maybe they can look into using some tooling that whole isn’t nix, it uses nix under the hood and still prices some benefits.
I heard about DevBox and Flox. Those at least try to provide a reproducible dev environment (note, I haven’t used them myself as I feel that the abstraction they do places limits on nix functionality, but then others might see it as a benefit)
I also am getting impression that as time progresses things are getting smoother over time. With poetry2nix for example the big problem are packages that depend on C libraries, as those are not specified as python dependencies, so poetry2nix has a override file which adds them.
Previously I very frequently had to update and contribute new packages there. I was a bit away from python as was assigned to work on a Go project for half a year and now starting to work on another python project and when tried to use it and things just worked. All I had to do was to use latest poetry2nix and my project then compiled to a working container.