[gaganyaan]

Not really. I introduced it to our Python projects at work and it's been great. Partially because of poetry2nix, and partially because it makes it easy to include other stuff like a specific version of Redis for testing purposes. Everybody gets the exact same dev environment, reducing a ton of "works on my machine".

[sevagh]

Presumably it also can fill the role of conda/mamba i.e. also managing C/C++ libraries in the same way in the nix environment, isolated from the system libraries?

[gaganyaan]

Yep, it can lock down exact versions of those libraries as well, which is great for not mucking about with lib versions between even different Ubuntu versions, not to mention distros or macOS.

[aragilar]

Except nix doesn't support Windows, which is best reason to use conda (having to support Windows).

[corethree]

virtualenv is the python way. For things like redis and other external web stuff, docker is the standard.

[gaganyaan]

Sure, that works. Or I can have it all in a single shell.nix file that covers everything and is super simple to use. It's great for handing off to coworkers that don't usually use Python.

[corethree]

It's not simple. The nix programming language is like untyped ML. Most people aren't used to it and even if you are familiar with it it gets hella hard to read. Learning curve is huge.

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

[ParetoOptimal]

> 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.

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

[corethree]

>1) not just as well because docker is repeatable, not reproducible

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.

[bigstrat2003]

I assume what they're getting at is that when you download a Docker image it'll always be the same (repeatable), but the image which is built from a Dockerfile may change even if the file does not (not reproducible).

[ElectricalUnion]

https://martinfowler.com/bliki/ReproducibleBuild.html and https://wiki.debian.org/ReproducibleBuilds and https://reproducible-builds.org/ says just because something is "repeatable", doesn't mean it is "reproducible".

[sevagh]

>It's not simple.

Neither is using virtualenvs for Python packages with native extensions.

[corethree]

Yeah I know. I'm saying the nix language is not simple. With docker you don't need virtual envs.

[gaganyaan]

nix is far simpler for consumption. My coworkers don't like fancy new things, and they haven't had any complaints. They don't have to dick around with half a dozen different commands to get everything set up, or bother with docker volumes/port mapping/etc. They just run nix-shell and it all works. That's all you have to do with a shell.nix file, it's very simple.

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.

[corethree]

It's the same thing for Docker. Just one command. The nix is much harder to deal with mainly because shell.nix is harder to read and write then a Docker file.

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.

[gaganyaan]

You're seriously overestimating how hard this is, especially with poetry2nix. I like docker just fine and have used it in a development workflow and it's a pain in the ass and should never be used for that. It's great for packaging stuff up for prod, though.

Also, one man's "DESIGNED" is another man's hacks. I don't see anything wrong with how nix works. Potato/potato, I guess.