Comment by ianthehenry | Hacker News Reader

Comment by ianthehenry | Hacker News Reader

Oh hi! Author here. Fun thing to wake up to.

I wanted to point something out that the series doesn't do a good job of highlighting:

You can use Nix alongside your existing package manager.

They won't conflict. You can set up dev environments with Nix without drinking the kool-aid. I still have Homebrew installed, and I still occasionally reach for it in the rare cases where Nix is missing some package I want to try. But I am sad every time I do: I never really realized how unbelievably slow Homebrew is until I tried Nix.

So if you're Nix-curious, you can try it out without committing to anything upfront. I didn't make the switch until part 19:

https://ianthehenry.com/posts/how-to-learn-nix/switching-fro...

Nix is weird and hard to learn, but it's a lot like git in that respect. Yes, the UI is terrible. You have to learn the difference between `reset --hard` and `reset --mixed` and it's weird and unintuitive but you eventually get over it.

And people are using it despite how unintuitive it is, because of how valuable it is to them. No one is arguing that `nix-env -qaP package` is a reasonable command to ask a fellow human being to type, but people are willing to type it anyway because the benefits are worth it. As a fun example, a few weeks ago I wrote up a little hack that I would not have even attempted before spending the time to learn Nix:

https://ianthehenry.com/posts/janet-game/how-to-patch-emacs/

from that newer blog post:

> So even if something bothers you about the software you use every day – even if you find a bug in tmux, or wish that you had some additional jq function or whatever – you probably aren’t going to do anything about it. It’s not worth it; it’s too hard.

> I am obviously projecting here: that is the way that I thought before I started using Nix. I never would have tried to change this Emacs behavior back then.

> But now?

> Now I can get a working build environment for any package I want, just by running nix-shell. I can write a patch, and I can ask Nix to automatically apply that patch to the latest version of the package. I don’t have to worry about maintaining my own fork or manually updating it – I can keep using all the same commands to list and upgrade and uninstall packages, regardless of what I’ve done to them.

I think this is what all the old greybeards have always been getting at when they talk about software freedom, this blurring of the line between user and contributor that is possible with F/OSS. I know for a fact that there are some HN posters who do use apt-get and related tools this way (that Debian developer who taught his kids to use Xmonad, for example). But I do think it's something Nix is especially good at, as a flexible, source-based package manager.

It's really nice to be able to treat your customized builds in a first-class way with a mature system for managing software.

Btw, if your main use case for this is customizing F/OSS, there's a SaaS offering you can use for free to recover binary caching without even having to set up a build server. Pretty cool if you have multiple computers! https://www.cachix.org/

`apt-get source` and `apt-get build-dep` is a wonderful thing! It's a shame there isn't more around that (like how to navigate the code to a large software package once you have it, eg Firefox).

I remember how awesome it was to switch from Homebrew to Nix, noticeably the speed. But there is something off about Nix: + Installation process, especially on Mac: nix, and then home-manager. And I don't even mention flake. Right now I'm settled with a helpful script from https://nix.dev/, but I don't say I'm fully confident. + How to add an external package which is not in nixpkgs. I have to learn Nix and dig Nix docs and ask too many questions to figure this process. In the end it is awesome but I could feel the barrier for beginner. + Documentation. It's easy to get started with some popular packages but it's a pain to customize your own. I always find myself banging my head to dig the information I need.

So in conclusion, Nix is awesome to use if you invest time to learn the Nix expression language. Otherwise you have to stuck with the default packages provided by nixpkgs.

I love nix as a concept. I have a couple concerns in practice.

* I don't want to learn nix, nor do I want to learn apt, brew, pip, npm, crates etc. beyond a handful basic commands: install, remove, list all, list package (version & deps), update (at version). A one page cheatsheet would be fantastic.

* There is a ton of QA work sunk in standard package manager workflows. Is there a way to leverage this work? You allude it is possible, hopefully there is a one page cheatsheet explaining how.

Regarding obscure command syntax, I use bash aliases to give names to the most common 7 git commands (which constitute 99% of my daily usage) and never have to remember any git command flags.

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