- hide warnings when requiring files repeatedly on a case-insensitive
filesystem and add reference to Ruby bugs
- add another case to check for command require failures
- also handle commands with `-` in them
Fixes#19125
We've already disabled installing casks/formulae from URLs and we
regularly tell people not to install from paths so let's just deprecate
this behaviour entirely.
Even Homebrew developers do not need to work this way.
- 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.
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 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.
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
```
- We should tell people to not report issues if they are running in an
unsupported configuration.
- We should tell people to run `brew update` before reporting issues if
they have `HOMEBREW_NO_AUTO_UPDATE` set.
- We should tell people to not report issues in more types of
exceptions.
- Warn people in `HOMEBREW_NO_AUTO_UPDATE` documentation.
- DRY up `brew.rb` exception handling.
Co-authored-by: Colin Dean <colindean@users.noreply.github.com>
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.
We warn sometimes when we tell people to build from source and it's
not supported but we don't actually warn non-developers when invoking
the various install commands so: let's start doing so.
While we're here, also update the existing messaging to reflect the fact
we're on Mastodon now too and we don't want maintainers being
individually bothered about errors either.
I've tried to balance having messages here vs. having them be so long
at the beginning of installation that they will be missed or be overly
obnoxious.
When either being in a non-default prefix or being on an unsupported
macOS version we expect most things to be built from source. In that
environment, do not allow HOMEBREW_INSTALL_FROM_API to be set.
Fixes#14475
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where relevant
- remove some duplicate checks
- better scope checks to just core tap formulae
The `stackprof` gem wasn't being included
correctly because it was missing the path
directory. This vendored gems path is added
later on in `load_path.rb`.
We export the GEM_PATH and GEM_HOME environment
variables in setup_gem_environment! so we
can use that information if we require the
`rubygems` gem first.
We're still getting a non-trivial number of issues from configurations
we don't support and don't plan to.
Let people know that we know their experience will not be good and what
to expect if they file issues.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
This came up in https://github.com/Homebrew/homebrew-bundle/issues/1108
wherein a user had unwittingly untapped some official taps that get
automatically tapped on first use and couldn't figure out why they
couldn't use the associated command.
