Youcan see my current Home Manager config in my lucperkins/nix-home-config repo on GitHub, which includes usage instructions in case you want to give my config a spin and make your own modifications. Clone and fork away!
The beauty of Nix is that every time you update your configuration, even a little tiny bit, you get a brand new /nix/store/***-home-manager-path directory with a new hashed path. This ensures that nothing is ever linking to the wrong place and that you never get collisions. To garbage collect your old paths, just run nix-collect-garbage.
The Homebrew package manager may be used on Linux and Windows Subsystem for Linux (WSL) 2. Homebrew was formerly referred to as Linuxbrew when running on Linux or WSL. Homebrew does not use any libraries provided by your host system, except glibc and gcc if they are new enough. Homebrew can install its own current versions of glibc and gcc for older distributions of Linux.
The installation script installs Homebrew to /home/linuxbrew/.linuxbrew using sudo. Homebrew does not use sudo after installation. Using /home/linuxbrew/.linuxbrew allows the use of most binary packages (bottles) which will not work when installing in e.g. your personal home directory.
The prefix /home/linuxbrew/.linuxbrew was chosen so that users without admin access can ask an admin to create a linuxbrew role account and still benefit from precompiled binaries. If you do not yourself have admin privileges, consider asking your admin staff to create a linuxbrew role account for you with home directory set to /home/linuxbrew.
Homebrew can run on 32-bit ARM (Raspberry Pi and others) and 64-bit ARM (AArch64), but as they lack binary packages (bottles) they are unsupported. Pull requests are welcome to improve the experience on ARM platforms.
Note: if you set these variables you are granting these repositories the same level of trust you currently grant to Homebrew itself. You should be extremely confident that these repositories will not be compromised.
You can instruct Homebrew to return to pre-4.0.0 behaviour by cloning the Homebrew/homebrew-core tap during installation by setting the HOMEBREW_NO_INSTALL_FROM_API environment variable with the following:
I have been using a standalone (i.e. no nix-darwin), flake-based, home-manager config on macOS for a while now, and love having a declarative setup. However, there are a few tools that are more easily installed through homebrew, as well as casks that have no counterpart on nix for macOS.
At the moment, I have installed homebrew separately, but I manage the config files of the homebrew-installed binaries (e.g. yabai, skhd, sketchybar) with home-manager using xdg.configFile and so on, as well as keeping a Brewfile in my dotfiles repo.
Declaratively configuring homebrew and launchctl are some of the major reasons for using nix-darwin. Maybe you can explain why nix-darwin is not an option for you, if for context more than anything else?
I do have sudo privileges, so I could go that route. I started with home-manager as it felt a more gradual way to familiarise myself with nix as a package manager. I guess I might feel brave enough soon to take the plunge and use nix-darwin.
Home Manager is best suited for user configuration, but the things you mention all belongs to system-wide configuration. For system-wide stuff, nix-darwin is the best tool for the job. Many people, myself included, use both.
Nix-Darwin is great, but the way it mixes per-user and systemwide responsibilities and uses sudo to switch between them (only working right when being launched unprivileged) is a big source of pain for me at work thanks to software we have to run which meddles with sudo behavior, requiring me to enter my password multiple times and breaking TouchID integration.
Homebrew is a free and open-source software package management system that simplifies the installation of software on Apple's operating system, macOS, as well as Linux. The name is intended to suggest the idea of building software on the Mac depending on the user's taste. Originally written by Max Howell, the package manager has gained popularity in the Ruby on Rails community and earned praise for its extensibility.[6] Homebrew has been recommended for its ease of use[7] as well as its integration into the command-line interface.[8] Homebrew is a member of the Open Source Collective,[9] and is run entirely by unpaid volunteers.[10]
Homebrew has made extensive use of GitHub to expand the support of several packages through user contributions. In 2010, Homebrew was the third-most-forked repository on GitHub.[11] In 2012, Homebrew had the largest number of new contributors on GitHub.[12] In 2013, Homebrew had both the largest number of contributors and issues closed of any project on GitHub.[13]
Homebrew has spawned several sub-projects such as Linuxbrew, a Linux port now officially merged into Homebrew;[14][15] Homebrew Cask, which builds upon Homebrew and focuses on the installation of GUI applications;[16] and "taps" dedicated to specific areas or programming languages like PHP.[17]
Homebrew was written by Max Howell in 2009.[1][18] In March 2013, Homebrew successfully completed a Kickstarter campaign to raise funds for servers to test and build formulae and managed to raise 14,859.[19] On December 13, 2013, the Homebrew repository migrated from Howell's GitHub account to its own project account.[20] In February 2015, due to downtime at SourceForge which resulted in binaries being unavailable, Homebrew moved their hosting to Bintray.[21] On September 21, 2016, Homebrew version 1.0.0 was released.[22] As of February 2021, Homebrew is maintained by a team of 34 people.[10] In January 2019, Linuxbrew was merged back into Homebrew, adding beta support for Linux and the Windows Subsystem for Linux to the Homebrew feature set.[23] On February 2, 2019, Homebrew version 2.0.0 was released.[24] On September 21, 2020, Homebrew version 2.5.2 was released with support for bottle taps (binary package repositories) via GitHub Releases.[25] Version 3.0.0 was released almost exactly two years after 2.0.0, on February 5, 2021, and added official support for Macs with Apple silicon.[26]On April 12, 2021, Homebrew version 3.1.0 was released completing their migration of bottles (binary packages) to GitHub Packages before the May 1, 2021 shutdown of Bintray as previously announced by JFrog.[27] On February 16, 2023, Homebrew version 4.0.0 was released which defaults to fetching Homebrew-maintained formulae from hosted JSON files rather than local Git-cloned taps.[28]
Homebrew is written in the Ruby programming language and targets the version of Ruby that comes installed with the macOS operating system. By default, it is installed into /usr/local on Intel-based machines and /opt/homebrew on Apple silicon.[29][30] The installation consists of a Git repository that enables users to update Homebrew by pulling an updated repository from GitHub.[citation needed] The package manager builds software from source using "formulae", Ruby scripts constructed with the Homebrew domain-specific language (DSL) for managing dependencies, downloading source files, and configuring and compiling software. Binary packages called "bottles" provide pre-built formulae with default options.[31]
Homebrew does not honor the default privileges of /usr/local; directory ownership is changed from root with group permissions for the wheel group to the installing user and the "admin" group. Specifically, the mode changes from drwxr-xr-x root wheel to drwxrwxr-x myuser admin.[32] All files, not just the directories, have their ownership changed by the installer. This is considered by some as a major security flaw.[33]
Homebrew collects installation, build error, and operating system version statistics via InfluxDB.[34] As of Homebrew 4.0.23, no data is collected via Google Analytics.[35] Users can view analytics data from the last 30, 90, and 365 days on the Homebrew website.[36]
While both MacPorts and Homebrew try to solve the same problem, they really are designed quite differently from each other. These differences become immediately evident once you start using them: I personally feel that MacPorts is clearly the better architected, more mature package manager of the two.
Homebrew makes several questionable design decisions, but one of these deserves its own section: the choice to explicitly eschew root (in fact, it will refuse to work at all if run this way). This fundamentally is a very bad idea: package managers that install software for all users of your computer, as Homebrew does by default, should always require elevated privileges to function correctly. This decision has important consequences for both security and usability, especially with the advent of System Integrity Protection in OS X El Capitan.
Of course, this design means that there is a single shared installation is among users, so running port requires elevated privileges whenever performing an operation that affects all users (which, admittedly, is most of the time). MacPorts is smart about this, though: it will shed permissions and run as the macports user whenever possible.
Nominally, MacPorts has over 20,000 ports ports available to install by default, while Homebrew has just shy of 5,000 formulae (plus a couple thousand more in homebrew/cask). Of course, the only thing this really tells us is that both of them have a lot of packages; both of these numbers are pretty meaningless as they contain things like versioned packages and other kinds of number-inflation. If you are looking for a popular, established package, neither will disappoint: packages like gcc, vim, and wget are available and up-to-date on both MacPorts and Homebrew.
These characteristics are present in almost every contentious decision that Homebrew has made. The discussion around the removal of options (which I was significantly involved in) is an almost perfect example of this: I brought up significant concerns regarding the justification provided for the change and came up with multiple compromises (to address problems I felt had not been adequately considered when the change was made), only to be brushed aside because the maintainers were unwilling to entertain any sort of discussion on the topic (the thread has now been locked and has had several comments deleted from it). In short, Homebrew continues to make decisions without consulting the community (and frequently with weak justification behind them), fails to communicate the changes with to users, and refuses to consider reasonable compromises at all.
3a8082e126