My understanding is that now https://github.com/Homebrew/brew/pull/15778
has been merged this should now work fine on both older macOS versions
and non-default prefixes so let's try this again.
For a long time people have requested some sort of configuration files
for Homebrew. Now: here's the first version of that.
Similarly to how you can configure Git for a system, a repository or
a user: you can configure Homebrew for a system, a prefix or a user.
The system-wide configuration file is `/etc/homebrew/brew.env`, the
prefix-specific configuration file is
`$HOMEBREW_PREFIX/etc/homebrew/brew.env`
and the user-specific configuration file is `~/.homebrew/brew.env`.
As we need to read these files from Bash in `bin/brew` (so they can)
influence functionality ASAP: they are in a simple format that Bash
can read. It may be that we have more complex array or hash data in
future that's configured through JSON or YAML (most likely JSON as we
use it more) and stored in a `brew.json`/`brew.yaml` file in the same
directory.
As this is relying on `eval` in Bash which is fairly dangerous: we
filter the lines with a regex to ensure we're only permitting setting
`HOMEBREW_*` variables and nothing more.
To give a bit of power to system administrators, the
`HOMEBREW_SYSTEM_ENV_TAKES_PRIORITY` variable can be set in
`/etc/homebrew/brew.env` to ensure that the system-wide configuration
file is loaded last and overrides any prefix or user settings.
Now that we have an actual location for configuration files, let's also
change the `brew livecheck` watchlist configuration file to be in this
directory and deprecate the existing location. As this is a developer
command and the mitigation is to just move the file: we don't need to
follow the normal deprecation process here.
The `strategy` block example for `GithubReleases` in the
`brew livecheck` documentation should be using `release` inside the
`#map` block instead of `json`. I accidentally overlooked one instance
of `json` when adapting the code from the `GithubLatest` example above
it.
- warn if running `brew postinstall` explicitly and there's no
`post_install` defined in the formula
- add a `post_install` alias for `brew postinstall` to make life
easier for those jumping between `postinstall` and `post_install` in
e.g. Homebrew development
- refactor `post_install` formula path logic into a new method for
improved readability
- handle the JSON API `post_install` formula path case
My understanding from conversations with Bo98 is that this should now
work fine on both older macOS versions and non-default prefixes.
Similarly, it's super confusing when this is set automatically and you
can't figure out why...
New installs don't tap `homebrew/core`, so `brew edit foo` fails with
`Error: Invalid usage: foo doesn't exist on disk.` for any package.
Add an instruction to run `brew tap homebrew/core` first, which fixes
this issue.
