Homebrew Bundle removed lockfile support in Homebrew 4.4.0 (Oct 2024):
the `--no-lock` CLI flag, the `HOMEBREW_BUNDLE_NO_LOCK` env var, and
the `no_lock` parameter in `installer.rb` are all dead code. Setting
`homebrew.global.lockfiles` has had no effect on current Homebrew
versions.
- Replace the `lockfiles` option with a hidden stub (matching `noLock`)
- Replace the `noLock` hard assertion with a shared deprecation warning
for both options
- Stop setting `HOMEBREW_BUNDLE_NO_LOCK` in `environment.variables`
- Remove the lockfiles paragraph from the `brewfile` option description
Whalebrew support was fully removed from Homebrew Bundle in
Homebrew 4.7.0 (Nov 2025). A `whalebrew` entry in a Brewfile now
raises `RuntimeError: Invalid Brewfile: undefined method 'whalebrew'`,
breaking the entire `brew bundle` invocation.
Use `mkRemovedOptionModule` so that existing configs get a clear
warning instead of an undefined-option error. Also removes the
auto-addition of `"whalebrew"` to `homebrew.brews` and the Brewfile
generation for Docker containers.
Add support for `cargo "pkg"` entries in the generated Brewfile. Homebrew
Bundle supports installing Rust crates via `cargo install`; the `rust`
formula is automatically installed if not already present.
Add support for `go "pkg"` entries in the generated Brewfile. Homebrew
Bundle supports installing Go packages via `go install`; the `go`
formula is automatically installed if not already present.
Both `brew bundle` formula and cask installers support a `postinstall`
option -- a shell command to run after the package is installed or
upgraded. The command only executes when the package actually changed,
not on every `brew bundle` run.
Examples from the Homebrew docs added to the `homebrew.brews` and
`homebrew.casks` option examples and tests.
Homebrew supports `link: :overwrite` which runs `brew link --overwrite`,
force-overwriting existing symlinks. Extract the existing
`restart_service` special-case logic into a reusable helper
(`mkBrewfileLineBoolOrSymbolString`) for options that can be either a
bool or a Ruby symbol in the Brewfile.
- Replace deprecated homebrew/cask-fonts with apple/apple tap example
- Update documentation links from archived homebrew-bundle to brew.sh/Brew-Bundle-and-Brewfile
- Update source file references to new location in main brew repository
Some systems set `secure_path` in sudoers. When this is set
the `PATH` variable is not set in the sudo environment. Using
`--preserve-env=PATH` ensures that the PATH env var is set properly
in those systems.
This is similar to the issue with [darwin-rebuild](https://github.com/nix-darwin/nix-darwin/issues/798)
not working with sudo on these systems.
This adds an optional explicit `homebrew.user` option that allows users
to avoid setting `system.primaryUser`, partly as a proof of concept
of what the interfaces should look like in the future. Homebrew only
officially support one global installation, so a singleton matches
upstream’s expectations; in practice, it may be useful for us to
nest this into `users.users.*.homebrew` instead, at the expense of
being an unsupported setup if used to its full potential. Since
that would be a breaking change to the inteface anyway, I think
adding `homebrew.user` for now is acceptable. (I think one native
Apple Silicon and one Rosetta 2 Homebrew installation – under
`/opt/homebrew` and `/usr/local` respectively – may be exceptions
to this lack of upstream support, but that would be complicated to
support even with `users.users.*.homebrew`.)
I’m not entirely sure where in system activation this should
go. Probably after the user defaults and launch agents stuff, to match
the existing logic in user activation, and I lean towards doing it
as late as possible; too early and we might not have the users and
groups required to bootstrap a Homebrew installation set up, but
as Homebrew installations could be fiddly and fail, doing it in the
middle could leave a partially‐activated system.
Probably it should be done in a launch agent or something instead, but
this is my best guess as to the appropriate place for now. The downside
is that activation scripts generally won’t be able to assume that the
Homebrew prefix is populated according to the current configuration,
but they probably shouldn’t be depending on that anyway?
Currently, setting `homebrew.masApps` causes `"mas"` to automatically
be added to `homebrew.brews`. Users who want to use Homebrew only
for managing App Store apps and casks, like me, can override this
by setting `homebrew.brews = lib.mkForce [ ];` and adding Nixpkgs’
`mas` to their `environment.systemPackages`.
When the activation script path no longer depends on the built
configuration’s `environment.systemPackages`, this will no longer
work. Since this was originally added before `mas` was packaged in
Nixpkgs and we now have a perfectly serviceable binary package,
we can add it to the `$PATH` when invoking Homebrew and skip the
automatic formula installation.
As the Homebrew `bin` directory still comes first, users who
specifically want the formula can restore the previous behaviour by
explicitly adding `"mas"` to `homebrew.brews`.
Closes: #1314
Some casks have extrenal dependencies managed by brew, neovide for
examples declares neovim as a dependency, a problem arises when you want
to use a nix managed neovim instead
`mkEnableOption` wraps its argument in a complete sentence with a
terminating full stop; an additional newline will add an incorrect
space before the end of the sentence in the rendered documentation,
and any additional verbiage that doesn't fit into the form "Whether to
enable [...]." is also incorrect. In the latter case, the description
can be overridden manually.
This process was automated by [my fork of `nix-doc-munge`]; thanks
to @pennae for writing this tool! It automatically checks that the
resulting documentation doesn't change, although my fork loosens
this a little to ignore some irrelevant whitespace and typographical
differences.
As of this commit there is no DocBook remaining in the options
documentation.
You can play along at home if you want to reproduce this commit:
$ NIX_PATH=nixpkgs=flake:nixpkgs/c1bca7fe84c646cfd4ebf3482c0e6317a0b13f22 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run github:emilazy/nix-doc-munge/0a7190f600027bf7baf6cb7139e4d69ac2f51062 \
{} +
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge
These help `nix-munge-doc` automate more of the Markdown conversion
process. See the following nixpkgs commits for explanations of many
of these changes:
* 275a34e0d8
* 694d5b19d3
* f1d39b6d61
* 16102dce2f
I couldn't think of any particularly good way to format the
`system.defaults` breadcrumbs, so I just made them standalone
paragraphs. They weren't rendering correctly in DocBook anyway.
