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>
I'm declaring bankruptcy on this entire approach:
1. We can attempt to match on versions, but this will fail
when the version of `gh` installed is built from `HEAD`
or similar.
2. We can match on dates instead (since `gh --version` also includes
the date), but this is even more brittle + implies a support
contract we don't actually have (we don't actually want
to say we support random dated builds between public releases
of `gh`).
This moves us back to a simpler approach: if `gh` is present,
we use it. If `gh` is not present, we attempt to install it
with `ensure_executable!`. If the user's `gh` is present but too old,
it'll fail during attestation verification with a reasonable error,
which IMO is fine for now since this is all still in beta.
Signed-off-by: William Woodruff <william@yossarian.net>
- Improve the error message when a cask or formula is forbidden by an
environment variable (fixes#17880)
- Move the `forbidden_tap_check` and `forbidden_cask_and_formula_check`
methods to the top of the `install` method, so that they are checked
before the main cask is downloaded.
- Previously this only included the formula name.
- But, for example in tests, we have "#{bin}/ansible-test",
not just "#{bin}/ansible". So handle that too.
- I decided to make the error message better by extracting the
binary name from the interpolation, but I'm not sure it was worth it.
```
$ brew audit --strict ansible
ansible
* line 580, col 29: Use `bin/"ansible-test"` instead of `"#{bin}/ansible-test"`
Error: 1 problem in 1 formula detected.
```
The regex to match Debian `orig` tarballs uses the standard regex for
versions like `1.2.3` but it won't match versions without a dot. The
`lcrack` formula uses a date-based version in the filename
(`lcrack_20040914.orig.tar.gz`) and `mkcue` uses a single number
(`mkcue_1.orig.tar.gz`), so we have to use a manual `version` in
these formulae.
This updates the regex to use the looser `NUMERIC_WITH_OPTIONAL_DOTS`
pattern, which will also match the aforementioned versions. I tested
this by checking versions of formulae before/after this change and
confirming that they remain the same after removing the `version`
calls from related formulae.
Let's use the disable date, if provided, and use 1 year after the
deprecation date otherwise, to display a better message for the
various outputs of deprecated package messages.
Also, provide an internal API for this that can be used by
Homebrew/actions.
This improves the load time of most brew commands. For an example of
one of the simplest commands this speeds up:
Without Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 525.0 ms ± 35.8 ms [User: 229.9 ms, System: 113.1 ms]
Range (min … max): 465.3 ms … 576.6 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 383.3 ms ± 25.1 ms [User: 133.0 ms, System: 72.1 ms]
Range (min … max): 353.0 ms … 443.6 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.37 ± 0.13 times faster than git checkout master; brew help
```
With Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 386.0 ms ± 30.9 ms [User: 130.2 ms, System: 93.8 ms]
Range (min … max): 359.5 ms … 469.3 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 330.2 ms ± 32.4 ms [User: 93.4 ms, System: 73.0 ms]
Range (min … max): 302.9 ms … 413.9 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.17 ± 0.15 times faster than git checkout master; brew help
```
