Currently, ruby files that are not in the Cask directory are
considered to be formulae if a Formula or HomebrewFormula directory
doesn't exist which doesn't make sense. We know that these should
only be in a few directories so we can check for that explicitly.
Beyond that the `Tap#cask_file?` and `Tap.formula_file?` methods
were only used inside update-report so it doesn't make sense to
turn them into pathnames and expand things when we know that
each string will be a relative path from a tap that we can just
check with a regex.
This change will stop other tap changes like new commands or
changes to other directories like lib/ from showing up as new formulae.
I tried opening a PR for this a long time ago but I got busy
with other things and it got closed by the stale bot.
- https://github.com/Homebrew/brew/pull/15489
This should avoid these getting included globally in future.
I found this list from a combination of
https://github.com/Homebrew/brew/pull/17707/files, looking at the
Gemfile and just looking around myself.
Loading different constants can be tricky with all the requires in
Homebrew so we want to strengthen the existing checks to make
sure that things are not getting required when there is a performance
penalty. This expands the existing check to include more constants
beyond `Formula` that we don't expect to be defined and that pull
in a lot of other dependencies.
- Move HOMEBREW_TAP_DIRECTORY to startup/config.rb because this file
holds more of the directory constants
- Rename `Commands.cmd_directories` to `Commands.tap_cmd_directories`
to better express that the commands come from taps
This file has the directory constants while the other one has regexes.
Just better organization.
We were selectively requiring the tap.rb file in a few places for
performance reasons. The main method we were referencing was the
`Tap.cmd_directories` method which uses `Pathname` and the `TAP_DIRECTORY`
constant internally. `Tap.cmd_directories` is mostly used in the `Commands`
module and that is loaded very early on in the program so it made sense
to move that command to that module. To facilitate that I moved the
`TAP_DIRECTORY` constant to the top-level and renamed it to
`HOMEBREW_TAP_DIRECTORY`. It now lies in the tap_constants.rb file.
A nice bonus of this refactor is that it speeds up loading external
commands since the tap.rb file is no longer required by default in
those cases.
- Remove/change data from bottle SBOM to avoid harming reproduciblity
- Add `schema_validation_errors` method to provide nicer test failures
- Add tests more tests for SBOM when bottling
- Cleanup SBOM tests to use more typical RSpec form and be DRYer
- We discovered that the following syntax in the formula `sqlsmith`
should actually be OK because the `\n` is like whitespace.
```ruby
cmd = %W[
#{bin}/sqlsmith
--threads=4
--timeout=10
]
shell_output(cmd)
```
- I got bored doing them manually.
- Also now more people can help with letters of the alphabet using `brew style --only=FormulaAuditStrict/Text --fix homebrew/core`.
- 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.
