Previously, the default temporary directory was /tmp on Linux and
/private/tmp on macOS. On many Linux distros, including at least Fedora,
/tmp is stored in RAM. This diverges from the behavior on macOS and has
led to bugs, most notably the inability to install large bottles on
memory-limited machines.
- do some optimisation of `require`s before Bootsnap
- remove `HOMEBREW_BOOTSTRAP` environment variable as it's set by
default
- add fast require in `bootsnap.rb` using logic from `ruby.sh`
- cleanup `bootsnap.rb` a bit
- remove setting `HOMEBREW_BOOTSNAP` in GitHub Actions
If this variable is set, `brew *env-sync` will only sync the exact
installed versions of formulae rather than all the patch (or, for node,
minor and patch) versions.
- 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>
