As a casual user of nix, this is the worst. I can never remember commands and it just increases barrier to entry. Git has a bad command line UI but nix is far worse even after their recent command line improvements.
Edit: that said, I do like using home-manager to manage configs across multiple machines even though it can be confusing.
I don’t quite follow the conclusion. Forcing values will not result in random operations on the store. Forcing values can only ever create store derivations, which is an internal representation of all derivations that were encountered while evaluating some expression. I won’t ever mutate existing data or remove anything from the store, nor will it actually build anything or fetch cached packages, so forcing values should be unproblematic. Store derivations can later be garbage collected.
But.. it doesn't really matter that much because half of the datastructures in Nix are so circular that you couldn't print them out anyway.
The glibc issue you ran into is actually a prime example of this problem, and the version shipped in nixpkgs is patched to allow multiple instances by changing various hardcoded paths to the glibc's path in the nix store.
`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 <cmd>` 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...
> deepSeq is basically useless because of how almost every datastructure is ciruclar
Circular references will cause "infinite recursion", and these will cause evaluation errors. So valid nix code will not contain circular references. Compositions of derivations create merkel DAGs. There are also fixed points, but deepSeq can still handle those scenarios.
> trace is almost useless because you can never know if a statement is a value or a computation.
use of trace creates a thunk. So it will always be a thunk.
> Derivations actually put something in your store when you evaluate them.
No. Instantiation will create store derivations, realizations will perform a build, and successful builds create store paths. `nix-instantiate '<nixpkgs>' --eval -A hello.version` Evaluates the expression, but doesn't produce a store derivation.
> Except that I don't need to know this for apt or any other package manager.
You're also probably not creating your own .deb's. You would seek other options.
> Nix is the only one that forces me to learn endless minutia about every single language.
Eventually you will to learn your problem domain. Just because you do python dev on ubuntu, doesn't eventually you will eventually need to know how python finds modules.
> Haha. HAHA. HAHHAHAHAHHA. Oh sorry. That wasn't laughter. That was me trying to hide my tears.
Hmm, I can't see your face. So don't worry about saving it.
> show-trace is about as useless of an addition as I can imagine.
Pretty useful for me, but I also use for work, and free time.
> Nix totally creates a file on your disk in this case. Yes, it doesn't "build" the package as in, it doesn't compile it or fetch it. But it actually does do something on your machine.
Sure?
> The terminology around nix is just disastrously bad.
Because the terms don't align exactly with other existing terms. Haskell has similar issues, where the terminology is foreign for many, but accurate.
> And conda works perfectly without this hack.
Well, conda tries to solve different things. It's definitely not a generic package manager. For supporting python use cases, conda does what it does.
Also, using escalated privileges to install packages is the norm for almost all other package managers. user-level installation is definitely the exception.
> I get it, nix people love nix and love to make excuses for its horrible failures. But seriously, other package managers do this beautifully. Can't we just sometimes accept reality?
Do what? FHS? How many borked distribution upgrades have occurred because of FHS incoherence.
> And that was 20 years ago. The 2.0 CLI is still a mess.
`nix-*` commands makes sense in context of a phd thesis. The `nix <cmd>` 2.0 cli, is definitely more ergonomic. Most package manager cli's until about 5 years ago were also pretty bad. Still remember having to use dpkg on ubuntu to fix some issues.
> Oh boy... how I wish this was true!
It is true, that's why I said it.
> Haskell is such a mess in Nix that there are two entire incompatible toolchains.
nixpkgs' haskellPackages is reflective of all hackage packages, and works well for consumption. If you're eluding to haskell.nix, that's a bit more complex and magical.
> Both of which are incredibly hard to use by the way.
This makes sense that it's hard for you.
> And Python packages which are pure are also a disaster!
The python package ecosystem is a hot mess for all distros [0] [1]. The "I can selectively choose small version ranges of dependencies to satisfy my singular use case" doesn't integrate well to distro's trying to present a coherent package set.
[0]: https://drewdevault.com/2021/11/16/Python-stop-screwing-dist... [1]: https://blogs.gentoo.org/mgorny/2021/11/07/the-future-of-pyt...
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 safe to inspect. This kills debugging.
- 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.
- 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.
- 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.
- 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.
Nix the package manager also has serious issues:
- 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!
- 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.
- 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.