Comment by ianthehenry | Hacker News Reader

Comment by ianthehenry | Hacker News Reader

Parent Full thread

The thing is, I don't think the one page cheat sheet is very useful.

npm is a great example of why: pretend that all you have is `npm install -g`. That's sort of how a traditional package manager, like Homebrew, works. But that's not typically how you use Nix, just like you don't typically globally install npm packages. Instead, you write package.json files -- which isn't very hard, because you already know JSON.

But in order to write the Nix equivalent, you have to learn the Nix expression language. You can just copy a template shell.nix file and modify it slightly (as you might for a package.json file), but it's likely that that will be frustrating, because... well, because you still have to learn about garbage collection, and channels, and lots of other incidental things that don't map as cleanly to traditional package managers.

There are cheat sheets, though. I linked my Homebrew <-> Nix translation guide above, and the NixOS wiki has one for apt-get:

https://nixos.wiki/wiki/Cheatsheet

But this requires so many asterisks as to be not extremely useful. For example, that page lists `nix-env -u` as an equivalent of `apt-get upgrade`, but it's not. `nix-env -u` is hopelessly broken and will not do what you want. There actually isn't a "right" way to upgrade packages if you're using nix-env. It's just not a thing that Nix can do.

Which sounds crazy at first glance, but remember: nix-env is like `npm -g`. Even though that's a first class concept in most package managers, it's sort of bolted onto the side of Nix, and accepting "the Nix way" of doing things is important to have a pleasant relationship with the tool.

> Instead, you write package.json files -- which isn't very hard, because you already know JSON.

Even with a package.json you will often use `npm install <package_name> --save`.

You don't go chasing a git commit hash on a third party site to do that

Right, npm (and other language-specific package managers) do dependency resolution in a first-class way and Nix doesn't. Nix resolves dependencies in the way that's typical of source-based package managers: when you name a package as a dependency, what you're depending on is whatever version of that package simultaneously inhabits the monorepo of build recipes as your package.

Language-specific package managers like NPM or Cargo or Composer are not designed for a universe in which packages inhabit a monorepo where compatibility is ensured simply by coordination of changes in that repo. They're built on top of a different kind of infrastructure.

They also face different challenges since their focus is much narrower, i.e., libraries in a single language with a single build system, rather than whole applications whose build system can freely change in a fairly open-ended way from version to version.

It would be pretty cool for Nix to have some version constraint solving built in, and for Nixpkgs to host more versions of many packages. There's precedent for that in a way that wouldn't require radical change to Nix and Nixpkgs in other source-based package managers like NetBSD Pkgsrc and Gentoo Portage. It would also be cool to provide some built-in machinery for pulling package recipes out of old versions of Nixpkgs (or searching a global registry of some other kind for them). Whether the latter happens will probably depend on the future of the flakes implementation, and extending it backwards will take manual work. There's already sort of a proof of concept, though, in the implementation of one tool for generating Python packages for use with Nix (mach-nix).

I forgot to mention that an in-depth resource like the OA is invaluable complement to terse cheatsheets for the 1% of the cases when the common commands are not sufficient. Thank you :)

Reply on news.ycombinator.com