The longest line below limit is 59 chars this way.
Warning: `brew install` ignores locally edited formulae if
`HOMEBREW_NO_INSTALL_FROM_API` is not set.
Ever since we started using this at runtime it's been polluting
the backtrace output. This makes it harder to debug errors and
increases the amount of info users have to paste into the box
when filing an issue.
This is a very direct approach. Essentially, we strip out
everything related to the `sorbet-runtime` gem whenever the top
line in the backtrace is unrelated to sorbet-runtime.
The hope is that this will allow errors related to sorbet to
be diagnosed easily while also reducing the backtrace size
for all other types of errors.
Sometimes it is useful to see the full backtrace though.
For those cases, we include the full backtrace when
`--verbose` is passed in and print a warning that the
Sorbet lines have been removed from the backtrace the
first time they are removed.
Note: This requires gems to be set up so that the call to
`Gem.paths.home` works correctly. For that reason, it must
be included after `utils/gems` which is included in
`standalone/load_path` already.
The cache here needs to be cleared when we are auditing multiple
os/arch combinations but not when we are running the audit only
for the current os/arch combination. This gives a 2x speed boost
to `brew audit --skip-style --except-version --tap=homebrew/core` locally.
In theory we could clear the cache less often by running all audits for
one os/arch combination at a time when auditing multiple os/arch combinations.
This would make the output a bit harder to follow and we don't seem to
run those checks on CI so I'm skipping that for now.
- check for cask.url in audit steps
- check for cask.version in audit steps
- check for cask.sha256 in fetch command
- stop omitting casks based on nil url in audit command
It would be nice to be able to omit casks from the audit
if the os is not supported but there is not easy way to
do that without updating the SimulateSystem code or
refactoring how MacOSRequirement's are defined in the DSL.
It's possible for casks to only run on certain os/arch
combinations but we don't check for them in the fetch and
audit commands.
At first, I tried to check if the macos version was satisfied
in a previous PR but that doesn't work correctly because
MacOSRequirement and ArchRequirement don't respect SimulateSystem.
Instead I'm just checking to see if the url stanza is defined
for each os/arch combination and skipping those casks where
it ends up being nil. This is kind of brute forcing it but
should work.
- more sensible/performant defaults: default to primary repositories
only for the last year rather than all repositories forever
- allow specifying more than one user at a time
- output the breakdown of contributions without needing `--csv`
- add a space before the `--csv` output
- consolidate some code
- avoid counting authored commits twice, to improve performance
- retry failed GitHub API calls (this happens often when querying all
maintainers)
- stop counting after we find 1000 commits for a given user to avoid
excessive API queries/pagination
This allows the correct bottling of `gnu-tar` dependencies (and
`gnu-tar` itself). It also installs `gnu-tar` at a more appropriate
time in the `brew bottle` command.
Even though the command already sets without_api that only
affects how named args are loaded. In this command, we used to load
many formulae and casks all at once using the API according to
user settings. Now we just mandate that all loading must skip the API.
- Load paths with no API when needed (e.g. for `brew edit`)
- Use no API mode for `brew log` as it's needed there
- Define sharding format for homebrew-cask and homebrew-core inside
`Tap` methods
- Create new formulae/casks in location defined by these `Tap` methods
- Fix a bug in Formulary that made sharded formulae lookup less
efficient (and possibly broke it for core and some API usage)
- Fix various other hardcoded Formula/Cask directory assumptions
Co-authored-by: Bo Anderson <mail@boanderson.me>
I noticed from
https://github.com/Homebrew/homebrew-core/actions/runs/5751070010 that
we're no longer creating reproducible bottles between macOS and Linux.
All macOS checksums have changed but Linux ones have not. The main
difference between the two platforms is the `gtar` version used so let's
always just use the formula on both platforms.
While we're here, clear up the ordering and comments a little on the
reproducible `tar` arguments so that it's easier to compare with the
reproducible builds archives documentation.
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.
