- This cop checks for the use of `FileUtils.rm_rf` and suggests using
`FileUtils.rm_r` because we should know if we couldn't delete a
thing for some reason, not just force it.
This should really be an allowlist rather than a denylist,
but for the time being this at least prevents someone from
causing an obtuse sandbox error by naming a file something like
"foo\".
Signed-off-by: William Woodruff <william@yossarian.net>
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.
