4 ms·

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

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-from-homebrew-to-nix/ 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/ https://ianthehenry.com/posts/janet-game/how-to-patch-emacs/

pxc 5y ago
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/ https://www.cachix.org/
- fragmede 5y ago
  `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).
angelzen 5y ago
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.
- ianthehenry 5y ago
  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 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.
  - dmitriid 5y ago
hiepph 5y ago
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/ 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.

pxc 5y ago

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/ https://www.cachix.org/

fragmede 5y ago
`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).

angelzen 5y ago

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.

ianthehenry 5y ago
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 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.
- dmitriid 5y ago

hiepph 5y ago

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/ 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.