nix-config VS homebrew-graph

> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors.

Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel).

I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machin... ):

  trace "FIXME: Which modules are artefacts of using QEMU to install?"

Where nixpkgs2105 is a pinned revision of the Nixpkgs repo, defined in another overlay. My current Nix config has pinned Nixpkgs versions going back to 2016. For example, here's a bunch of such overrides:

https://github.com/Warbo/nix-config/blob/master/overrides/fi...

At the moment I'm using niv to manage the pinned Nixpkgs versions (the 'repoXXXX' entries):

https://github.com/Warbo/nix-helpers/blob/master/nix/sources...

`nix-env` is an imperative command, whilst writing a .nix file is declarative. In particular, the latter can be managed using git.

For example, here's a system-wide config dating back to Feb 2015: https://github.com/Warbo/nix-config

(That's actually a NixOS config; my macOS config is in a private repo, but it imports that repo to define its "one big system package")

> I'd like to see other configs from nix users too if you're still here!

Here's mine https://github.com/warbo/nix-config

I've used Nix/NixOS for about 8 years, but not delved into flakes yet.

wat.

Of course the recursive update policy is going to be weirdly painful for some users! Homebrew doesn't even attempt to encode some very basic aspects of dependency. The choice you outline above is one that is not faced by most package managers, because they don't make this mistake. The naive wheel reinvention with Homebrew is so eternally disappointing, and it inevitably explains a lot of the pain users experience with it.

> Homebrew upgrades dependencies and dependents of those dependencies (which, admittedly, can feel like unrelated)

One relatively non-disruptive thing you might be able to do to make this behavior less surprising to users is (offer a way to?) print the dependency tree for package installations/upgrades that pull in upgrades of their ‘siblings’. You'd probably want to just do it in a textual way, but this project seems to model the kind of logic you'd want for printing dependency trees with Homebrew as it exists.[2]

—

1: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

2: https://github.com/martido/homebrew-graph/blob/master/cmd/br...