I know I'm a Nix elitist but I really don't understand why people don't just use Nix for all their package management.
This was at the "let's download the package repository to get started" step. So, meh...
1. Install Nix from https://nixos.org/download.html
2. Find the package from https://search.nixos.org/packages
3. Start a shell with `nix-shell -p <name>`, have the package available in it
Sorry, no.
> So, switch to using both?
This is an option, yes. Plus, it has the added benefit of you not needing to manage `brew doctor`, `brew cleanup`, etc. yourself. So you're not stuck with weird packages you installed once, never needed again, and forgot to clean up.
It's strange that people are so against declarative systems, or even file-based OS configuration. When I get my new Macbook I was up-and-running within a few minutes. I can't imagine maintaining a list of brews I need to re-install just to set up everything + my configs + everything else. Nix Darwin just made this so ridiculously easy.
Plus I can share almost all of my configuration with my Linux setups so I have a near-consistent environment whether I'm on Mac or Linux.
The overhead of remembering the names for Brew, Apt, Snap, or whatever package managers exist seems like a lot of overhead, and I just value declarative, reproducible systems. Managing my packages on the fly?
Sorry, no.
I haven’t had time to try Nix yet, but HomeBrew does have a declarative-ish workflow that I’ve been using for years:
Brew Bundle [1] lets you have a plaintext file listing all packages you want installed on your system. Add a line for stuff you want installed, delete a line for stuff you want removed, invoke it the right way and it will install/remove packages until your system matches the list. The initial list can be generated by “brew bundle dump” or something like that.
For configuration, I find that a normal dotfile repo cloned into my ~/.config (with a script that maintains symlinks to config files in e.g. ~/Library) works well enough for my use.
In Nix terms, it uses the module system to generate a Brewfile, and then it invokes the brew CLI against that file in the activation script.
Nix or no Nix, it's definitely a better way to use Homebrew than ad-hoc, imo!
I'm not sure why you think there is any 'config' involved. Perhaps you're conflating Nix the package manager with NixOS? Nix is many things, but it's also just a package manager like any other. For example:
nix profile install nixpkgs#vim # installs a package into your environment
nix shell nixpkgs#binwalk nixpkgs#vim # drops you into a shell with the given packages
nix run nixpkgs#firefox # runs the mainProgram of the given package
The aforementioned commands are the "experimental" Nix 2.4 CLI commands that integrate with Nix Flakes. They are only experimental in name though, their status of being experimental being sort of a meme at this point. I recommend using these new commands (you can opt in by supplying a command-line flag or by tweaking the package manager config).
Packages that are not in active use (e.g. packages that you've referred to in 'nix shell' or 'nix run' invocations that are not installed using 'nix profile') are due for garbage collection. The garbage collection settings can be configured (either through NixOS, home-manager or the package manager's standalone configuration). The garbage collection can also be triggred manually. This makes experimenting with programs that you don't necessarily want to keep a joy.
The 'nixpkgs' in the aforementioned invocations is a default input that is set during installation. It refers to the nixpkgs package archive's flake's master branch's latest revision (https://github.com/nixos/nixpkgs). The available inputs are configurable (again, either through NixOS, home-manager or the package manager's standalone configuration).
It surely is complex, but I think you're intrinsically devaluing the importance of dependency management. Your important 'stuff to do' is built on top of a lot of software, getting that supply chain right (and reproducible) is at least as important.
For example, if you have a JS project with a package.json, Nix offers node2nix as a way to transform that package.json into Nix-like expressions. But in an alternate universe npm and lockfiles would "work" well enough to where we wouldn't need to rely on nix for package pinning.
There's all this work put into reproducibility that thinks that the answers are around adding wrappers around the existing tooling. It's good as a last resort, but if those efforts were going more into each language's ecosystem may we would end up in a scenario where each packaging tool didn't have to come up with its own magic way of doing things.
Nix and Bazel are complex because they try to hard to work well despite the tooling, rather than getting tooling to a place where all these layers of hacks were not an issue. And so downstream of that, "simple" tools become too complex from all the incidental complexity introduced by this way of doing things.
Nix the language doesn't have such a thing (would be a bit of a category error), and nixpkgs the ecosystem is so far away from that kind of thing...
Language ecosystems around sharing source code cannot exist as they do today if every dependency pinned its dependencies to specific versions. Source distribution like that has different requirements than binaries.
You're saying "just use nix". Nix does not provide this. This is a fundamental feature of programming language package managers. I would love for Nix to have an interesting answer to this problem, but I think that if nixpkgs continues to exist in its current form (following more of an apt model), it will be hard for the Nix community to come up with an answer that fits well. Nixpkgs is mostly about distributing compiled assets, while programming language package managers are mostly about distributing source code. The important parts are different!