Fish didn't support `$(...)` substitution until v3.4.0, but the command
didn't work with just parenthesis, so rewrite the test to prepend an
empty string if MANPATH is non-empty (to trigger a leading colon).
Only manipulate INFOPATH in Fish if Homebrew not in path already.
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.
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>
This adds a new method to either move the `gh` formula to the front
of the formula list to be installed or checks that the `gh` formula
is already installed some other way.
The `Homebrew::CLI::NamedArgs` class often returns frozen arrays so this one cannot
be easily modified in-place here. We just overwrite it instead.
I also updated the `brew reinstall` command logic to match for consistency.
```console
$ brew upgrade gh --verbose --debug
...
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromAPILoader): loading gh
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromAPILoader): loading gh
Error: can't modify frozen Array: [#<Formula gh (stable) /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/g/gh.rb>]
/usr/local/Homebrew/Library/Homebrew/cmd/upgrade.rb:139:in `delete'
/usr/local/Homebrew/Library/Homebrew/cmd/upgrade.rb:139:in `run'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/call_validation.rb:270:in `bind_call'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/call_validation.rb:270:in `validate_call'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'
```
This is primarily intended to resolve the `uninitialized constant
Utils::Backtrace` error in `formula_versions.rb:60` but I expanded it
to try to cover all existing usage of `Utils::Backtrace`.
I've followed the existing pattern, where `utils/backtrace` is
required in the context of where it's used. Many of these cases use
`Backtrace` in a conditional manner, so I've tried to ensure that the
`require` follows suit.
