In practice, it's not that restricting. It's pretty rare to find something actually requiring a more recent version. (And there's slow progress in updating it)
Randy Eckenrode is doing work pushing this forward almost every day, and constantly posting little updates on Matrix in the Nix on macOS channel. If anyone reading this is invested in that work, you can track it just by idling in the room. I'm sure he'd appreciate help or even just sincere expressions of encouragement or gratitude.
Granted, it’s not restrictive if you only want to use Nix for general utilities and Unix libraries. But it’s extremely restricting if you want to use Nix to manage macOS apps. And I love Nix, so of course I want to do that :)
This looks interesting. Personally I have been moving away from homebrew and use nix-darwin (https://github.com/LnL7/nix-darwin) with home-manager for my local software. It has been working great, but there are still a few packages that require Homebrew due to their complex build process. Maybe this helps.
That said, nix-darwin is still useful for doing system level things, like enabling Touch ID for `sudo`. I use that in my config: https://github.com/srid/nixos-config
I actually wrote a script which creates a trampoline launcher for this. It has its flaws but it solves the spotlight issue, and supports pinning to Dock across updates.
This is great! I run a script with mkalias[1] which works fine but all icons have this ugly arrow. Yours works perfectly - only thing missing is the icon in the spotlight search.
I also do that, but when I search for emacs for example I get like 2-3 different ones and they are named as the full path in the nix store. That sometimes goes away after some time with indexing, but sometimes it does not.
And another annoying issue is that sometimes even when theres only one, its called by the path, and Im not a wizard so I don’t know if that path is the latest, so I am still using outdated software because its not launching the newest version.
- Homebrew can be a pain. I've had several occasions where it broke something on my system with its magic. The main reason for this is its imperative (as opposed to declarative) nature. You can easily install things that clash with other software installed on your system.
- You can easily install different versions of the same software without having to worry about clashes
- Fully declarative configuration. You know exactly what is installed on your system at any time.
- Portable reproducible configuration. Imagine you get a new laptop. Because you have have your system configuration declared with nix and home-manager you can copy the configuration file, run install, and your system is set up, exactly the way the old one was.
- To add to the above, you can also do the same with non-MacOS systems if you make your config conditional on MacOS. I sometimes want to work on a remote Linux machine. I can set up a full dev environment with all the tools I use locally with a single command now.
If you want a more declarative approach to Homebrew: ‘brew bundle’ uses ‘Brewfile’s for this. You can share these on macOS and Linux and add similar conditionals.
Not nearly as reproducible but: this is something I’m working on. Stay tuned…
The existing Brewfile functionality what Nix-Darwin's Homebrew module currently uses behind the scenes, so any improvements here might also benefit some Nix users on macOS (including me!).
The conditionals and cross-platform stuff might also make it possible to write a single module here that enables use of Homebrew as an escape hatch both on macOS and Linux/NixOS, which would maybe be kinda cool.
I use Linux at home but when I got my work MacBook I was able to get an identical setup (shell aliases, git config, shell plugins, nvim, etc etc) with very minimal effort and not needing to understand a macOS way of installing all these programs like with e.g. homebrew.
Declarative, reproducible, and no fiddling with macOS specific stuff.
Plus, we had instructions in our wiki for dealing with homebrew package installation failures and conflicts with macOS-installed versions of required software, needing to install other programs like Ruby version manager, etc to fix these issues. but with Nix I just setup a devshell and got the exact version we needed installed with no issues.
And this can be pinned and reproduced for every developer using Nix, eliminating the hassle for everyone.
Package installation and personal config in a single declarative language, reproducible with a single command, and shareable across platforms. But that's just scratching the surface of Nix's capabilities.
I believe they've somewhat fixed this, it prompts you on first-run whether you want to accept analytics or not. Makes it quite explicit if you want to opt-in or opt-out.
> Homebrew gathers anonymous analytics using InfluxDB. You will be notified the first time you run brew update or install Homebrew. Analytics are not enabled until after this notice is shown, to ensure that you can opt out without ever sending analytics data.
it's ok, sneak literally just comments this on any mention of Homebrew. we've made many changes to analytics but, according to sneak, unless we move to opt-out: we're spyware.
weird how sneak doesn't post this on posts about all of the closed-source companies that use server-side analytics you cannot audit and data you cannot access.
There's no expectation of privacy when you send data to a server. There is when you run local software.
It's unethical for anyone, yourself included, to use an end user's device to spy on them without their consent. Transmitting their activity without explicit opt-in is spying, full stop. It's not spying to monitor your own server when servicing client requests as that is obviously done with the consent of the device's owner (yourself).
I'm not sure why you bring it up; surely you understand the difference between your own computer and someone else's? It feels like you are perhaps approaching it in bad faith.
There is no amount of ad hominem that will make producing and shipping spyware into an ethical choice.
Somehow projects much larger than your own, also run by volunteers, such as Debian, not only survive, but thrive, without spyware of their own, and also with pervasive policies that patch out spyware and phone-home and other such misfeatures in their packages. Nixpkgs manages to continue to grow without spying on their users, too.
If you really thought users would consent, you'd go opt-in. If you maintain the stance that opt-out is acceptable, it is implicit that you believe that not enough users would consent, which means you are intentionally violating their consent given that you know that. Hence, the ethical issue, which handwaving doesn't change.
Debian knows this. It's a shame that Homebrew doesn't. Normally you see for-profit enterprises selling their users out with surveillance; you have no revenue targets to hit so I'm not sure why you persist in this behavior.
> it's ok, sneak literally just comments this on any mention of Homebrew
I wouldn't have to if you would surface for your users when the software you provided them uploads their usage data. Most of your users are unaware of it.
I'll bet you $10k USD cash that if you printed some messages to the console each time you hit the analytics endpoint with a message that "brew analytics off" would disable it, you'd lose a double digit percentage of your inbound data within 100 hours. You won't take this bet and you won't surface the tracking in realtime because you know it's only giving you the data so long as users remain unaware of your unethical behavior.
Also, parhamn explicitly asked for reasons people might switch. This is the primary reason I use Nixpkgs and not homebrew, so it's a direct and accurate answer to their question. You might be surprised but there are lots of people who choose software based on the behavior (and resulting trust level) of the developers.
> There's no expectation of privacy when you send data to a server. There is when you run local software.
To engage on this point: Brew is server software (most installs happen via 'bottles'), no? Presumably most package distros keep track of which packages are installed and how often (e.g. Pip/NPM even publish their data). Even if you install from source github/mirrors/etc they have that data too. I'm sure the same is true in nix too? Curious how you categorized "brew" as not server-y software? And how nix possibly gets around the mirrors/code-distribution services from having access to similar data?
Though my point is mostly moot if you point to a place in the brew source code that is taking more personal information from my computer that a load balancer wouldn't have access to.
> Presumably most package distros keep track of which packages are installed and how often (e.g. Pip/NPM even publish their data).
This isn’t true. Most distributions do not collect this information. There are a few package managers that do as you note, but there are also some that explicitly hide it from package publishers (the Go module proxy cache comes to mind).
Nix and the big linux distros specifically avoid collecting this information. Brew has code to deliver it to additional endpoints without consent.
I always have brew available because I inevitably run into issues with Nix packages (primarily managed by home-manager) on a pretty regular basis. Feels like I would be going in the opposite direction by wrapping them in Nix.
It seems to show up mostly in Python-based applications. Recently, I tried adding pyinfra to my system, but it failed to run because of some weird missing dependencies that I could never figure out.
The other big issues are languages. Most compilers and what not will build artifacts linked to the Nix store, which can result in surprising side effects. I tried switching to pyenv using Nix but then I had strange side-effects when trying to use it with poetry. So now I just install all of my language tools using homebrew and have had zero issues since.
Reading the comments, may be it is worth clarifying: this allows macOS users with nix package manager to install brew cask (I.e. typically GUI program that companies releases as pkg or dmg, etc., such as Mathematica, GitHub Desktop, Adobe CC…) without having brew at all.
I.e. it “steals” those brew cask formula and automatically repackage them as nix packages.
A closely related usage would be macOS with nix with nix-darwin, and using nix-darwin config to includes brew casks. This way, nix-darwin assumes brew exists and uses brew to install those casks.
This does have a major distinction on where the applications actually located, where some applications would upset if it is not inside /Applications.
