Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

211–220 of 361 posts

Re: The Curse of NixOS

#211

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are saf…

> - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging.

`lib.deepSeq` can be used to fully evaluate a thunk. `lib.trace` can be used to emit a log each time a value gets evaluated.

> - Everything in Nix is recursive, datastructures contain copies of themselves as hacks to avoid building proper APIs. So again, you can't print anything, even if you're sure that printing the object won't do something crazy to your store.

derivations are just a dictionary of information, passed to a `derivation` function; which communicates to nix that it should be built/realised. There is a minimal API for a derivation, which is just `name` and `builder` in attr set. In general, the builder will refer to script which may have additional levers. For example, `stdenv.mkDerivation` also expects a src.

> - There are almost no APIs and no uniformity in Nix. Packages are given total freedom to do anything. The Python ecosystem works totally differently from the Haskell one which works totally differently from the C++ one. It's insane. They use different datastructures, functions, etc. To do the same thing.

"Just because two things are similar, doesn't mean they're the same". I wouldn't expect building openssl to look similar to building ripgrep, a python package, or a node package. Each domain has it's own oddities. Python for example expects packages to be installed at `${prefix}/lib/python-${python.majorVersion}.${python.minorVersion}/site-package`

> - The Nix language has impossible error messages. You will get stuck. You can't view values and you can't get error messages. There's no moving forward from that unless you ask someone.

This has significantly improved with nix 2.4+. `--show-trace` will now show you an entire stack trace with files and line numbers.

> - Laziness in Nix is different from laziness in Haskell. In Haskell, it's mostly about performance improvements and some cool tricks here and there. In Nix, laziness fundamentally means something: you build up packages and you force them to install them.

For haskell, I think it was originally a side-effect of how they implemented the language. For nixpkgs, this is still important because nixpkgs is just a large dictionary (attr set). However, doing something like `nix-shell -p cargo`, will avoid having to evaluate all of nixpkgs, just what I need for cargo.

Also, nix doesn't build a package when it evaluates it. Building is done as part of realization (which many commands do implicitly).

https://book.divnix.com/ch04-02-realise-a-derivation.html

> - You cannot install Nix in your home account without root permissions (yes, there are hacks, but they break terribly). So Nix is actually less isolated and less portable than something like Anaconda!

This is because `/nix` needs to exist, and can't be a symlink. sudo only needs to be done once. user installs can be performed after that.

> - The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc.

The `nix-*` commands are a carry-over from the phd days of nix. Where they are reflect closely to the underlying nix machinery. The nix 2.0 `nix ` cli tries to better reflect "user scenarios", but still kind of a WIP. So I agree, cli is probably one of the weakest aspects of nix right now.

> - In exchange for making some hard things easy, Nix makes a lot of easy things very hard. Sure, it will manage an isolated environment. But, now you want a package from pip that isn't in Nix? There is literally no way for you to figure out how to do this, you need to find a tutorial online, hope it's up to date enough to work, and follow it step by step. And.. there's a good chance you misunderstood what the tutorial was doing and won't have the correct environment at the end.

Depends on the toolchain. Rust and Go builds are almost trivial to support now. Python and other ecosystems which rely on a lot of impure behavior will have the most impedance mismatch with nix.

Mixing a nix python packages with venv is described here: https://nixos.org/manual/nixpkgs/stable/#how-to-consume-pyth...

Re: The Curse of NixOS

#212

I've been using Nix for about a year. I don't use NixOS but home-manager and nix-darwin. Just about every single time I've tried to do something new, it has ended up being way more complicated than I thought at first. - Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. -…

>Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop.

Just don’t use emacs ;)

In all seriousness, were you pulling from unstable? Disallowing installation because the hydra build is failing has gotten me, albeit for an obscure package I never use.

>And flakes are explained in...uh...well, you'll figure it out.

This is a funny quirk in the community I’ve seen, where everyone talks about using flakes but has a very difficult time of saying how. I finally figured out the weird incantation to get flakes to work. It was not trivial. (And the reason I’m not saying it here is because I simply don’t remember.)

Re: The Curse of NixOS

#214
post #178

Earlier quoted context omitted.

This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coord…

Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it. But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix fo…

I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out.

[1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

Re: The Curse of NixOS

#215
post #212

I've been using Nix for about a year. I don't use NixOS but home-manager and nix-darwin. Just about every single time I've tried to do something new, it has ended up being way more complicated than I thought at first. - Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. -…

>Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. Just don’t use emacs ;) In all seriousness, were you pulling from unstable? Disallowing installation because the hydra build is failing has gotten me, albeit for an obscure package I never use. >And flakes are explained…

> I finally figured out the weird incantation to get flakes to work. It was not trivial.

Care to share with the class? ;)

Re: The Curse of NixOS

#216

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user pac…

I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixp…

As someone who is using NixOS for 8+ years, I do agree with both your problems.

(1) I do find that it's very rare having to implement a low level transitive dependency from scratch (most low-level system dependencies are already there, and for dependencies of a specific programming-language ecosystem you'd usually auto-generate them from things like `yarn2nix` or `poetry2nix`). However, I agree that once you need to do that for non-trivial library it quickly becomes painful and require intimate knowledge of both the build system and Nix environment.

(2) This is my main issue. My workflow is also having a local `nixpkgs` clone, and go find the function and the parameters I can use every time I don't remember how to use it. I also think that it is sustainable. There are many exciting improvements going on with the new CLI, so hopefully we will get nicer error messages and better tooling support in near future.

> but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences.

There are pain points, but the advantages for me were indispensable. Being able to pin dependencies accurately, reproduce an exact development environment deterministically, and use the single language to define applications, configurations, and even entire system images is a great benefit that I would need to use 10+ tools with individual quirks otherwise.

Re: The Curse of NixOS

#217

I've been using Nix for about a year. I don't use NixOS but home-manager and nix-darwin. Just about every single time I've tried to do something new, it has ended up being way more complicated than I thought at first. - Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. -…

> Setting up a local environment for a Go project? No problem. Er, except some tools need to be installed globally, quite against the Nix philosophy.

I have yet to encounter an environment I can't fit into a nix she'll, what requires globally installed tools? Sounds like a bug.

Re: The Curse of NixOS

#218

Earlier quoted context omitted.

What really helped me were the videos of Jon Ringer: https://www.youtube.com/user/elitespartan117j27

Glad someone found them useful :)

I cannot thank you enough for these. It is so much useful to see someone doing a task.

Re: The Curse of NixOS

#219

Earlier quoted context omitted.

Ha, nice! Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.

People have tried: https://github.com/jkcfg/jk But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.

> The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts?

Yeah, that's a good point.

I don't see any reason determinism requires a functional paradigm. That said, the functional language communities probably value determinism more than the others, currently.

Choosing a language whose community values align with your needs can be a good thing.

Re: The Curse of NixOS

#220

I used to think the ideas of NixOS were great, but then I learned about `ostree`, and in my opinion things like Project Atomic (in Fedora), are probably more pragmatic or straightforward idiomatic implementation of those ideas. In essence the software packages resemble how git works behind the curtain. Git has a bunch of objects with cryptic names resembling hashsum's, and those are the files in your git working tree…

Not just ostree. Using butane / ignition configs to setup coreos is very nice.
Post reply on HN