- use the system font instead of Helvetica
- cleanup font definitions
- add extra newline to `CONCLUSION.rtf` to next steps not showing up
without a click
- add actual hyperlinks to `CONCLUSION.rtf`
Fixes#15793
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
- This should help avoid this regressing
- Remove existing Homebrew installation(s)
- Install it twice to ensure that installing over the top of an existing
installation works as expected
- Remove existing API cache to ensure we have the freshest files from
the API in our package
When we're automatically setting `HOMEBREW_NO_INSTALL_FROM_API`
when on an old macOS version or with a non-default prefix (e.g. cases
where you're going to be mostly building from source).
My initial plan was to set
`HOMEBREW_AUTOMATICALLY_SET_NO_INSTALL_FROM_API` in these cases but
it's used differently enough it made sense to add another internal
variable instead: `HOMEBREW_INSTALL_FROM_API_UNSUPPORTED`.
At the moment this is only used to avoid printing the "You have set
`HOMEBREW_NO_INSTALL_FROM_API`" message inside `brew update` but may
make sense to use in other places over time.
Ideally, we'll get rid of these automatic sets of
`HOMEBREW_NO_INSTALL_FROM_API` and perhaps even the variable entirely.
