- use e.g. `$HOMEBREW_*` for cases where only the environment variable
is the entire backtick-quoted string
- use e.g. `${HOMEBREW_*}` for cases where the environment variable is
part of a backtick-quoted string to make clear what parts are variable
and what parts are not
- use `export HOMEBREW_*=...` for cases where we're talking about
setting the environment variable (because it likely needs to be
exported to work how they want)
Inspired by https://github.com/Homebrew/homebrew-bundle/pull/1579 making
similar changes for Homebrew/homebrew-bundle.
- handle reading from variables that may not be defined yet
- avoid unnecessary handling of defined variables
- fix incorrect `env_config.rbi` file entry
- add `HOMEBREW_NO_FORCE_BREW_WRAPPER` to disable
`HOMEBREW_FORCE_BREW_WRAPPER` functionality if needed
Allow the ability for a system administrator to use
`HOMEBREW_BREW_WRAPPER` and `HOMEBREW_FORCE_BREW_WRAPPER` variables to
enforce the usage of a particular `brew` command for non-trivial (e.g.
`brew --prefix` is considered trivial, it doesn't need to write to the
prefix) Homebrew commands.
This also introduces a `HOMEBREW_ORIGINAL_BREW_FILE` variable for some
internal usage; `HOMEBREW_BREW_FILE` was being used internally for
both "how should we shell out to Homebrew" and "what should we use
to check permissions on Homebrew". `HOMEBREW_ORIGINAL_BREW_FILE` is
now used just for the latter case.
Inspired by conversation in
https://github.com/Homebrew/homebrew-bundle/pull/1551 which suggested
this was worth fixing in wider than just `brew bundle`.
If set, this will update the Homebrew API formula or cask data even if
`HOMEBREW_NO_AUTO_UPDATE` is set.
This is useful in cases where you want to update the cached API data but
don't want to update Homebrew itself.
Co-authored-by: Bo Anderson <mail@boanderson.me>
Before:
```
❯ HOMEBREW_NO_ANALYTICS=0 brew formula-analytics --days-ago=2
Error: Calling HOMEBREW_NO_ANALYTICS=0 is deprecated! Use If you wish to enable HOMEBREW_NO_ANALYTICS, use HOMEBREW_NO_ANALYTICS=1
If you wish to disable HOMEBREW_NO_ANALYTICS, use HOMEBREW_NO_ANALYTICS= (an empty value). instead.
```
After:
```
❯ HOMEBREW_NO_ANALYTICS=0 brew formula-analytics --days-ago=2
Error: Calling HOMEBREW_NO_ANALYTICS=0 is deprecated! Use HOMEBREW_NO_ANALYTICS=1 to enable and HOMEBREW_NO_ANALYTICS= (an empty value) to disable instead.
```
Our autobump workflow sets the author and committer to the user who
triggered the workflow, defaulting to @BrewTestBot for scheduled runs.
This can be confusing for maintainers when GitHub shows up as
"Unverified" because the commit is signed with @BrewTestBot's key.[^1]
Let's fix that by configuring our autobump workflow to always commit as
@BrewTestBot, so that the committer matches the GPG signature. To do
that, we need to add support for setting `GIT_COMMITTER_NAME` and
`GIT_COMMITTER_EMAIL`.
[^1]: See, for example, Homebrew/homebrew-core#197234.
`HOMEBREW_FORBIDDEN_LICENSES` now actually checks for valid SPDX license
identifiers rather than requiring the user to guess.
When an identifier is invalid, it will be ignore and warned about
instead.
The way we handle boolean environment variables is a bit unfortunate.
For example, setting `HOMEBREW_EVAL_ALL=false` actually enables
`HOMEBREW_EVAL_ALL`.
Let's fix this by deprecating setting boolean environment variables to
common false-y values (`false`, `0`, `nil`, `no`, and `off`) so that we
can later ignore these false-y values when reading boolean environment
variables.
My experience recently playing around with our locking behaviour is
that, while mostly seamless and not seen by users, it's leaks
implementation details a bit too heavily.
As a result, the following improvements are in this commit:
- Ensure that, whenever possible, we tell the user the actual command
that is holding a given lock instead of the lock name (an internal
implementation detail)
- Make the locking error output a little more consistent and user
friendly
- Add a `DownloadLock` class to simplify locking downloads
- Add a `HOMEBREW_LOCK_CONTEXT` variable to allow adding additional
context for logging error messages
- Lock paths and leave deciding how this translates to lock names up
to the locking code itself
- Lock the Cellar/Caskroom paths explicitly rather than implicitly
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Take 2 of https://github.com/Homebrew/brew/pull/17692 but with:
- provide and document `HOMEBREW_NO_VERIFY_ATTESTATIONS`
- don't try to run unless there's GitHub credentials
- don't try to run unless `gh` is installed
- don't try to run in CI
While we're here:
- split out a `Homebrew::EnvConfig.devcmdrun?` helper method
- add some missing `Homebrew::EnvConfig.github_api_token` presence
checks
`autoremove` is destructive, and it can be difficult for users to
recover from it occuring when they weren't expecting it.
Fixes#17363FixesHomebrew/discussions#5395
This reverts commit 3d114161b3c3f1a95b94e8530f5bc45bb44bbbd9.
This reverts commit efb14a0ec264c4ef408dbbd5330905dd230e979c.
This fits the use-case I've heard multiple times where people want to
rely exclusively on their artifact provider.
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Adds the basic attestation verification APIs, as well
as a pre-pour check against `HOMEBREW_VERIFY_ATTESTATIONS`
that verifies the attestation (or backfill as necessary)
for bottles from homebrew-core.
Signed-off-by: William Woodruff <william@yossarian.net>
We already had `HOMEBREW_FORBIDDEN_LICENSES` but this commit adds
`HOMEBREW_FORBIDDEN_CASKS`, `HOMEBREW_FORBIDDEN_FORMULAE` and
`HOMEBREW_FORBIDDEN_TAPS` for also forbidding those.
Relatedly, add `HOMEBREW_FORBIDDEN_OWNER` and
`HOMEBREW_FORBIDDEN_OWNER_CONTACT` to allow customising these
messages.
There were no existing tests for `HOMEBREW_FORBIDDEN_LICENSES` so have
added more tests for all of these checks.
Co-authored-by: Bo Anderson <mail@boanderson.me>
- We should tell people to not report issues if they are running in an
unsupported configuration.
- We should tell people to run `brew update` before reporting issues if
they have `HOMEBREW_NO_AUTO_UPDATE` set.
- We should tell people to not report issues in more types of
exceptions.
- Warn people in `HOMEBREW_NO_AUTO_UPDATE` documentation.
- DRY up `brew.rb` exception handling.
Co-authored-by: Colin Dean <colindean@users.noreply.github.com>
This environment variable allows telling Homebrew to use the `SUDO_USER`
variable to `sudo` through that user when Homebrew (Cask) attempts to
run `sudo`.
While we're here, clarify in some messaging that we're running `sudo`
and that that's the password we're asking for; the specific password is
configuration dependent and not the specific password for the user.
Similarly, remove the `Package installers may write to any location`
output; it's kinda spammy and doesn't feel like the right place.
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.
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.
Previously, the behavior was to warn users that a cask was already
installed and then skip modifying the installed version. This is
different to how we handled things with formulas. For them we would
upgrade any already installed formulas. This just brings casks in line
with what we already do with formulas.
Changes:
- cmd/install: Upgrade already installed casks if HOMEBREW_NO_INSTALL_UPGRADE
is not set
- env_config: Update wording of HOMEBREW_NO_INSTALL_UPGRADE to include casks
- remove error that was only used to alert about already installed casks
Note:
- The upgrade command for casks defaults to --greedy when you pass named casks
to the command which means that this will always default to that behavior
since you must specify the name of the cask when installing.
