It's good for a c or c++ project where libraries are very environment specific. But most modern languages have their own package/environment managers which makes Nix redundant.
One docker file and a poetry file works just as well. And is simpler. It's literally the same thing but using os primitives to manage the environment rather then shell tricks. Makes more sense to me to use a dedicated os primitive for the task it was designed to be used for.
Additionally docker-compose allows you to manage a constellation of environments simultaneously. This is nowhere near as straightforward with nix.
I love nix but being honest here. It's not definitively the best.
The biggest reason right now to avoid it is adoption. Most people won't know what to do with a shell.nix
1) not just as well because docker is repeatable, not reproducible
2) not if you need GPU acceleration which is a headache in docker, but not Nix shells
> Additionally docker-compose allows you to manage a constellation of environments simultaneously. This is nowhere near as straightforward with nix.
- devenv.sh - arion - https://flakular.in/intro
> Most people won't know what to do with a shell.nix
The same was once true for Dockerfile
Not sure what you're saying here but most likely you're referring to some obscure pedantic difference. Effectively speaking docker and nix shell achieve similar objectives.
>2) not if you need GPU acceleration which is a headache in docker, but not Nix shells
This is true. But this is the only clear benefit I see.
>- devenv.sh - arion - https://flakular.in/intro
right. So? I said nowhere near as straightforward. This isn't straightforward. It's an obscure solution.
>The same was once true for Dockerfile
False. DockerFiles are much more intuitive because it's just a declarative config. With Nix shell it's mostly people who like haskell or OCaml who are into that style of syntax. I like it but clearly that syntax has not caught on for years and years and years. Quite likely Nix will never catch on to that level too.
Neither is using virtualenvs for Python packages with native extensions.
It is harder to write on average atm, but it's very much worth it to me when it comes to sharing code for development. Also, LLMs help quite a bit when writing nix.
Additionally nix uses shell hacks to get everything working. Docker uses an os primitive DESIGNED for this very use case.
And additionally, because docker uses os primitives you can use docker-compose to manage multiple processes on multiple different environments simultaneously. Something that's much harder to do with nix shell.
Also, one man's "DESIGNED" is another man's hacks. I don't see anything wrong with how nix works. Potato/potato, I guess.
I think I know what you're getting at. nix-shell provides a fast way to get access to that specific shell environment which is a bit more annoying to do with docker. All docker needs to do is provide this interface by default and the only surface level differences between the two techniques is really just the configuration.
>Also, one man's "DESIGNED" is another man's hacks. I don't see anything wrong with how nix works. Potato/potato, I guess.
By any colloquial usage of the term "designed" in this context by any unbiased party, it's obvious Nix is more hacky by any charitable interpretation. NixOS is a layer on top of linux, containers are a linux feature. Thus creating a layer on top of linux to use existing features is the more hacky less elegant solution.
It can actually go in the other direction. Rather then use shell tricks Nix can also use containers under the hood. Overall though the API for docker is superior in terms of editing config files but not switching shells. Additionally the underlying implementation for docker is also superior.
Your main problem is with the API which is just opinionated.
a) Unless you literally write everything in one language, you will have to deal with learning, supporting and fixing bugs in N different package/environment managers instead of just one.
b) If you have a project that uses several languages (say, a Python webapp with C++ extensions and frontend templates in Typescript), then Nix is the only solution that will integrate this mess under one umbrella.
b. C++ is the only one that would benefit from nix here because C++ dependencies are usually installed externally. There's no folder with all the external sources in the project. Even so this can be achieved with docker. If you want you can have docker call some other scripting language to install everything if you want "one language" which is essentially what you're doing with nix.
b. No, docker is not a solution. Docker is another problem and a separate maintenance nightmare.
(Nix solves maintenance problems at scale, Docker explodes them exponentially. I would not ever recommend using Docker for anything except personal computing devices you don't care about.)
There are many python packages that have other dependencies not managed by Python package management. The pain of figuring out what those implicit dependencies are is effectively removed for users when configured as a nix shell.