4 ms·

I collaborate with people that use macOS while I use Linux. For reproducible environments, Nix has served us well. Despite the myth, it is not hard to use unle

by nextos 2y ago

I collaborate with people that use macOS while I use Linux. For reproducible environments, Nix has served us well. Despite the myth, it is not hard to use unless you need to package something complicated or messy. Then it may become hard. The advantage of Nix is total version reproducibility and declarativeness. It's quite reassuring to know things are exactly the same on all computers.

zelphirkalt 2y ago
I am fully on board with having reproducible declarative setups, line Nix or Guix offer. I want to note though, that the versions and original code may be the same, but it can still happen that something behaves differently on another OS. The code of some version of a package can intentionally do things differently on another OS. So you are not 100% safe from MacOS disturbing things. I wish though, that at my job people were as far as using Nix oder Guix though. Still a long way off of that. Wish people would explore more on and off the job, to realize the potential.
- nextos 2y ago
  Sure, but if you run the same Nix flake on two macOS machines with the same architecture, it will have the same behavior. Most of package managers don't offer that guarantee. Only Guix has a similar level of assurance? Nix openly recognizes outputs are different per platform, x86_64-linux is different from aarch64-darwin. Impossible not to, as ultimately architectures may behave differently.
- mplanchard 2y ago
  What we did at our job was I set up a nix config for myself, because I wanted it. When new people onboarded, they had two options: install this list of software or install nix and it’ll all get installed automatically. Enough people chose to use the nix config over time that it became the de facto standard.
  - hamandcheese 2y ago
    I like this strategy. Nix can be tricky to explain, so sometimes showing is much easier than telling.
- hamandcheese 2y ago
  Although Nix seems to be becoming more mainstream, I still have yet to encounter a (forgive me for lack of a better word) normie that uses it. I feel somewhat blessed that I get to work on tools at a company that can support a dedicated tools team. We are free to use the best tool for the job without needing to worry about popularity contests, and nix has truly been a game changer for us.
  - nextos 2y ago
    I think it is already seeing some adoption at normal & boring companies, which is a sign of maturity. Frankly, the biggest problem is that it needs some better docs, i.e. some serious corporate funding to get them written.
lijok 2y ago
It’s not a myth, Nix is incredibly complicated to get into and is actively hostile towards its users with the abysmal DSL and documentation. Every company we’ve tried to introduce it in has failed to adopt it primarily due to its incredibly steep learning curve
- mplanchard 2y ago
  It is quite complicated to understand or to set up, yes, but I agree that it is easy to use. We use it at work for our dev environments. Like two or three of us are able to actually add packages, adjust nix configs, etc. Everyone else just runs `direnv allow` and automatically gets everything they need to build and run out software.
  - okanat 2y ago
    If you don't have enough manpower who can control and collaborate on the development of the environment, the project will not succeed to be adopted. Programming language-specific dependency tools succeeded due to their user friendliness, however abysmal they are in multi-language / OS dependent environments (and I despise them for that reason). Cargo.toml, go.mod, conan.txt, Dockerfile etc. all are can be understood by basically all members of a dev team. You cannot say the same for Nix for most devs in a team.
    - mplanchard 2y ago
      Our direct experience counteracts this point. We have docs on how to add nix dependencies, and a file where they’re defined. For anything already packaged in nix, everyone can figure out how to add a line in that file to add something to everyone’s dev environment. We have over 3 years only wound up having to write our own derivations for two or three things. We still use language-specific tools for those dependencies, though, since that is what people are familiar with. I think this strikes a fine balance: nix describes the “operating system” that we all work in, and then Cargo, npm, etc lockfiles describe each language’s dependencies.
  - bsder 2y ago
password4321 2y ago
Is Nix still hard to uninstall on macOS? That's what scared me off but it's been years now...
- someguy101010 2y ago
  this installer comes with an uninstaller https://install.determinate.systems/ https://install.determinate.systems/
  - password4321 2y ago
    Thanks for the link. Apparently there were issues even as recently as 4 months ago, specifically conflicts between the determinate installer and nix-darwin though I'm not sure they are intended to be used together. https://news.ycombinator.com/item?id=40158558#40159195 https://news.ycombinator.com/item?id=40158558#40159195
    - pxc 2y ago
      The issue is just that Nix-Darwin doesn't 'own' your system, and it's conservative about blowing away existing files when installing files that it has generated. So if it detects that some file it wants to install conflicts with an existing one, it throws its hands up and tells you to deal with it before it will proceed. As it happens, /etc/nix/nix.conf is one file where such a potential conflict can occur. As an optimization, I think it will (sometimes? always? idr) replace a file if the existing one and its intended replacement have the same contents. The defaults /etc/nix/nix.conf in the mainline Nix installer and the defaults for /etc/nix/nix.conf in Nix-Darwin are the same, so it doesn't complain there. But the Determinate Nix Installer ships a nix.conf with different settings, so Nix-Darwin refuses to replace it, to avoid clobbering your (the Determinate Nix Installer's) settings 'changes'. There's no real compatibility issue, and the Determinate Nix Installer is doubtless intended to be used with any Nix-based software, including Nix-Darwin, Home Manager, etc. Nix-Darwin installation is just a bit hairy, as it's unfortunately always been. NixOS is a better experience in that respect, and you should consider running NixOS in a VM if you want to get a feel for that kind of systemwide, declarative Nix configuration without worrying about installing it against a foreign base system. (If you do learn your way around nixos-rebuild, you won't need the Nix-Darwin installer anyway.)
rtpg 2y ago
I've had nix disappear out from under me a couple times on Mac, enough for me to start drifting away from home manager. Sucks cuz I like the tooling! But seriously, let's say you have a Python project (like a Django application with a couple requirements in your `requirements.txt`), what is the least disruptive way to get it working? Many things I've looked at involved doing one-time transformations of requirements files or otherwise easy-to-desync things...

by nextos 2y ago

zelphirkalt 2y ago

I am fully on board with having reproducible declarative setups, line Nix or Guix offer. I want to note though, that the versions and original code may be the same, but it can still happen that something behaves differently on another OS. The code of some version of a package can intentionally do things differently on another OS. So you are not 100% safe from MacOS disturbing things. I wish though, that at my job people were as far as using Nix oder Guix though. Still a long way off of that. Wish people would explore more on and off the job, to realize the potential.

nextos 2y ago
Sure, but if you run the same Nix flake on two macOS machines with the same architecture, it will have the same behavior. Most of package managers don't offer that guarantee. Only Guix has a similar level of assurance? Nix openly recognizes outputs are different per platform, x86_64-linux is different from aarch64-darwin. Impossible not to, as ultimately architectures may behave differently.
mplanchard 2y ago
What we did at our job was I set up a nix config for myself, because I wanted it. When new people onboarded, they had two options: install this list of software or install nix and it’ll all get installed automatically. Enough people chose to use the nix config over time that it became the de facto standard.
- hamandcheese 2y ago
  I like this strategy. Nix can be tricky to explain, so sometimes showing is much easier than telling.
hamandcheese 2y ago
Although Nix seems to be becoming more mainstream, I still have yet to encounter a (forgive me for lack of a better word) normie that uses it. I feel somewhat blessed that I get to work on tools at a company that can support a dedicated tools team. We are free to use the best tool for the job without needing to worry about popularity contests, and nix has truly been a game changer for us.
- nextos 2y ago
  I think it is already seeing some adoption at normal & boring companies, which is a sign of maturity. Frankly, the biggest problem is that it needs some better docs, i.e. some serious corporate funding to get them written.

lijok 2y ago

It’s not a myth, Nix is incredibly complicated to get into and is actively hostile towards its users with the abysmal DSL and documentation. Every company we’ve tried to introduce it in has failed to adopt it primarily due to its incredibly steep learning curve

mplanchard 2y ago
It is quite complicated to understand or to set up, yes, but I agree that it is easy to use. We use it at work for our dev environments. Like two or three of us are able to actually add packages, adjust nix configs, etc. Everyone else just runs `direnv allow` and automatically gets everything they need to build and run out software.
- okanat 2y ago
  If you don't have enough manpower who can control and collaborate on the development of the environment, the project will not succeed to be adopted. Programming language-specific dependency tools succeeded due to their user friendliness, however abysmal they are in multi-language / OS dependent environments (and I despise them for that reason). Cargo.toml, go.mod, conan.txt, Dockerfile etc. all are can be understood by basically all members of a dev team. You cannot say the same for Nix for most devs in a team.
  - mplanchard 2y ago
    Our direct experience counteracts this point. We have docs on how to add nix dependencies, and a file where they’re defined. For anything already packaged in nix, everyone can figure out how to add a line in that file to add something to everyone’s dev environment. We have over 3 years only wound up having to write our own derivations for two or three things. We still use language-specific tools for those dependencies, though, since that is what people are familiar with. I think this strikes a fine balance: nix describes the “operating system” that we all work in, and then Cargo, npm, etc lockfiles describe each language’s dependencies.
- bsder 2y ago

password4321 2y ago

Is Nix still hard to uninstall on macOS? That's what scared me off but it's been years now...

someguy101010 2y ago
this installer comes with an uninstaller https://install.determinate.systems/ https://install.determinate.systems/
- password4321 2y ago
  Thanks for the link. Apparently there were issues even as recently as 4 months ago, specifically conflicts between the determinate installer and nix-darwin though I'm not sure they are intended to be used together. https://news.ycombinator.com/item?id=40158558#40159195 https://news.ycombinator.com/item?id=40158558#40159195
  - pxc 2y ago
    The issue is just that Nix-Darwin doesn't 'own' your system, and it's conservative about blowing away existing files when installing files that it has generated. So if it detects that some file it wants to install conflicts with an existing one, it throws its hands up and tells you to deal with it before it will proceed. As it happens, /etc/nix/nix.conf is one file where such a potential conflict can occur. As an optimization, I think it will (sometimes? always? idr) replace a file if the existing one and its intended replacement have the same contents. The defaults /etc/nix/nix.conf in the mainline Nix installer and the defaults for /etc/nix/nix.conf in Nix-Darwin are the same, so it doesn't complain there. But the Determinate Nix Installer ships a nix.conf with different settings, so Nix-Darwin refuses to replace it, to avoid clobbering your (the Determinate Nix Installer's) settings 'changes'. There's no real compatibility issue, and the Determinate Nix Installer is doubtless intended to be used with any Nix-based software, including Nix-Darwin, Home Manager, etc. Nix-Darwin installation is just a bit hairy, as it's unfortunately always been. NixOS is a better experience in that respect, and you should consider running NixOS in a VM if you want to get a feel for that kind of systemwide, declarative Nix configuration without worrying about installing it against a foreign base system. (If you do learn your way around nixos-rebuild, you won't need the Nix-Darwin installer anyway.)

rtpg 2y ago

I've had nix disappear out from under me a couple times on Mac, enough for me to start drifting away from home manager. Sucks cuz I like the tooling! But seriously, let's say you have a Python project (like a Django application with a couple requirements in your `requirements.txt`), what is the least disruptive way to get it working? Many things I've looked at involved doing one-time transformations of requirements files or otherwise easy-to-desync things...