4 ms·

I am all-in on nixos. I've also experienced those problems, but I for one am glad that those don't work. Let me explain. My use-case for Nix is to make my buil

I am all-in on nixos. I've also experienced those problems, but I for one am glad that those don't work. Let me explain. My use-case for Nix is to make my build system so reproducible that, if I get back to the project in five years, it should still compile, and if I give it to someone else, they should be able to make it work without any issue. Like the install steps for them should be as simple as "Install nix, then run `nix build .`". If that doesn't work, then I've failed. About your issue. It's unclear what it is given you give so little information, but I often run into similar problem of native bindings in NodeJS and Python not working failing at runtime. I've found that very often, those native bindings are distributed as prebuilt blobs. This obviously doesn't work on NixOS, because those prebuilt blobs will depend on paths that aren't present in NixOS. Here's the thing: That's not a NixOS bug. It's a bug with that package, which should check whether the prebuilt blob will work on your distro. Most don't though, and just assume the user runs Ubuntu or something. Here's the thing: That's not a NixOS exclusive issue - NixOS just makes it much, much more visible. I sometimes (though more rarely) had similar problems on old Debians or very new ArchLinux, where I'd have, say, a different openssl version and everything would break. Anyone that has a distro that deviates slightly from how the blob was generated will run into the same issues. At least with nix, once I have a recipe that works, I can be more or less guaranteed that the resulting flake will work reliably for everyone, everywhere. The only thing that could break it is if the source of the packages goes down. And that is great. That's my number one use-case. And for this, Nix is absolutely prime-time ready, and in fact it's the only package manager that has such high guarantees around.

zeec123 5y ago
I fully agree, but which there would be an escape hatch when needed. It is especially frustrating for python developers.
qudat 5y ago
> It's a bug with that package, which should check whether the prebuilt blob will work on your distro. I used nix on arch. I tried using nix via flakes and it didn't work. Then I removed flake from the project, loaded `nvm` and ran it again: it works. For both `nix` and `nvm` the underlying OS was the same. I buy your argument but at the end of the day, I have to get work done. I also feel like I need to mention that I have already sunk dozens of hours getting nix to work properly, this was really the last straw for me. Nix debugging fatigue got the best of me. Again I need to mention, my flake file had two packages: node and yarn -- and this didn't work for a project with native bindings.
- roblabla 5y ago
  Yes, for what it's worth I don't mean to diminish your experience. Nix definitely requires pouring a lot of time to get to a working state, is very under-documented, has terrible error messages, will cause errors that don't exist elsewhere, and has no clear "best practice" guide on how to use it. Those are all super annoying pain-points and I do hope they'll get better over time. At the end of the day, it's a bit of a balancing act. For me, the up-front work of getting a nix build up was definitely worth it, as it allowed my collaborators to get up to speed on complex projects with complex build systems quickly, and gave me a very simple way to reproduce old binaries when I need to bissect bugs. But it definitely took a huge up-front investment. If all you're after is a way to pin your toolchains, I echo the recommendation of asdf made in a sibling comment. I use it on simpler projects where I just need to pin a language version (and let the language tooling pin the rest of the dependency tree - package.lock-style). It will often be enough, and is much easier to get started with! The only thing that won't pin will be system dependencies (like openssl and such), but that is often an acceptable tradeoff.
kristjansson 5y ago
This is a maximalist position and an admirable goal. As far as I can tell though, this forces Nix (or the developer) to get into the business of re-packaging entire ecosystems.

zeec123 5y ago

I fully agree, but which there would be an escape hatch when needed. It is especially frustrating for python developers.

qudat 5y ago

> It's a bug with that package, which should check whether the prebuilt blob will work on your distro. I used nix on arch. I tried using nix via flakes and it didn't work. Then I removed flake from the project, loaded `nvm` and ran it again: it works. For both `nix` and `nvm` the underlying OS was the same. I buy your argument but at the end of the day, I have to get work done. I also feel like I need to mention that I have already sunk dozens of hours getting nix to work properly, this was really the last straw for me. Nix debugging fatigue got the best of me. Again I need to mention, my flake file had two packages: node and yarn -- and this didn't work for a project with native bindings.

roblabla 5y ago
Yes, for what it's worth I don't mean to diminish your experience. Nix definitely requires pouring a lot of time to get to a working state, is very under-documented, has terrible error messages, will cause errors that don't exist elsewhere, and has no clear "best practice" guide on how to use it. Those are all super annoying pain-points and I do hope they'll get better over time. At the end of the day, it's a bit of a balancing act. For me, the up-front work of getting a nix build up was definitely worth it, as it allowed my collaborators to get up to speed on complex projects with complex build systems quickly, and gave me a very simple way to reproduce old binaries when I need to bissect bugs. But it definitely took a huge up-front investment. If all you're after is a way to pin your toolchains, I echo the recommendation of asdf made in a sibling comment. I use it on simpler projects where I just need to pin a language version (and let the language tooling pin the rest of the dependency tree - package.lock-style). It will often be enough, and is much easier to get started with! The only thing that won't pin will be system dependencies (like openssl and such), but that is often an acceptable tradeoff.

kristjansson 5y ago

This is a maximalist position and an admirable goal. As far as I can tell though, this forces Nix (or the developer) to get into the business of re-packaging entire ecosystems.