This is a (relatively, for this Bash script) expensive operation that
can be trivially cached so: let's do so.
Speedup on my machine:
```
$ hyperfine "brew --version" "HOMEBREW_VERSION_CACHE=1 brew --version"
Benchmark 1: brew --version
Time (mean ± σ): 173.4 ms ± 5.1 ms [User: 28.7 ms, System: 67.0 ms]
Range (min … max): 167.3 ms … 182.9 ms 15 runs
Benchmark 2: HOMEBREW_VERSION_CACHE=1 brew --version
Time (mean ± σ): 145.9 ms ± 4.0 ms [User: 22.4 ms, System: 33.9 ms]
Range (min … max): 140.0 ms … 154.5 ms 17 runs
Summary
HOMEBREW_VERSION_CACHE=1 brew --version ran
1.19 ± 0.05 times faster than brew --version
```
Co-authored-by: Bo Anderson <mail@boanderson.me>
This avoids can avoid UID/EUID related issues with Ruby scripts passed
over `stdin` clashing with Ruby security features.
It's also just a bit nicer to have Ruby scripts in files instead.
While we're here:
- refactor some shared logic into a new `setup-gem-home-bundle-gemfile`
function in `ruby.sh`
- do some general cleanup of `lock.sh`
- prioritise `flock` over `python` in `lock.sh`
- in `brew.sh` split the `case` into those cases that take a single or
no arguments and those that take multiple arguments or handle
multiple commands. This considerably speeds up the
`brew shellenv bash` case that wasn't being handled here before.
- add `setup-ruby` to the list of commands that can be called quickly
by `brew.sh` without additional setup. This speeds up the
`brew setup-ruby` no-op case by ~10x.
- add a parameter to `setup-ruby` to avoid running Bundler if the
command doesn't need it. This makes many more cases for
`brew setup-ruby` to be no-op cases.
- Remove the (now) unused `HOMEBREW_RUBY3` check in `setup-ruby`.
- Improve argument handling in `command_path.sh` to allow it to be
used as a function in `setup-ruby.sh`.
- Add a new RuboCop to check usage of `install_bundler_gems!` is only
inside `dev-cmd` (or a few other acceptable places).
- Use new `processed_source.file_path` API in `formula_cop.rb`
- Add a (large) speedup by moving some logic to Bash for the typical
case of a normal or dev-cmd, Bash or Ruby command.
- Make `brew command` a non-developer command, I don't think it makes
sense to consider it something needed for developing Homebrew.
- Update the manpage/tests/RBI accordingly.
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
When doing an `install`, `outdated` or `upgrade` and referring to a
formula or cask in a specific tap: you probably want to get the latest
version of that formula/cask more often than the default 1 or 24 hours.
Let's check for arguments for these commands that look appropriate and
auto-update every 5 minutes in that case.
- Output a message every time auto-update is run rather than a 3 second
timer. This makes it more obvious that Homebrew isn't just sitting
doing nothing for 2.9 seconds.
- Output a message when running `brew update` so Homebrew doesn't just
sit there silently doing nothing.
- Update all taps when `brew update` is run, not just those hosted on
GitHub. This makes it more obvious that people don't need to explictly
run `brew update` "just in case".
- As a result of this, remove `brew tap --force-auto-update` as it's no
longer necessary.
This variable was getting filtered out before so it wasn't possible
for us to use it as the default for HOMEBREW_DEFAULT_CACHE
and HOMEBREW_DEFAULT_LOGS.
- split jobs into build/test/deploy
- test package on both macOS Intel and Apple Silicon
- cleanup some argument handling
- use `HOMEBREW_MACOS_OLDEST_SUPPORTED` naming to be consistent with
`brew.sh`
- note in `brew.sh` that `Distribution.xml` also needs updated (and do
so)
- various other little bits of style cleanup
We have no commands with Sorbet disabled and have had Sorbet enabled
for developers for a decent amount of time. As a result, we can enable
it for everyone who has run a developer command.
This also allows a bunch of `raise TypeError`s to be removed in favour
of relying on Sorbet here instead.
My understanding is that now https://github.com/Homebrew/brew/pull/15778
has been merged this should now work fine on both older macOS versions
and non-default prefixes so let's try this again.
- warn if running `brew postinstall` explicitly and there's no
`post_install` defined in the formula
- add a `post_install` alias for `brew postinstall` to make life
easier for those jumping between `postinstall` and `post_install` in
e.g. Homebrew development
- refactor `post_install` formula path logic into a new method for
improved readability
- handle the JSON API `post_install` formula path case
When we're automatically setting `HOMEBREW_NO_INSTALL_FROM_API`
when on an old macOS version or with a non-default prefix (e.g. cases
where you're going to be mostly building from source).
My initial plan was to set
`HOMEBREW_AUTOMATICALLY_SET_NO_INSTALL_FROM_API` in these cases but
it's used differently enough it made sense to add another internal
variable instead: `HOMEBREW_INSTALL_FROM_API_UNSUPPORTED`.
At the moment this is only used to avoid printing the "You have set
`HOMEBREW_NO_INSTALL_FROM_API`" message inside `brew update` but may
make sense to use in other places over time.
Ideally, we'll get rid of these automatic sets of
`HOMEBREW_NO_INSTALL_FROM_API` and perhaps even the variable entirely.
My understanding from conversations with Bo98 is that this should now
work fine on both older macOS versions and non-default prefixes.
Similarly, it's super confusing when this is set automatically and you
can't figure out why...
Correct `HOMEBREW_PREFIX`, and its only dependent up to that point, `HOMEBREW_REPOSITORY`, if the defaults contain symlinks. For example:
```console
$ realpath /home/linuxbrew/.linuxbrew
/var/home/linuxbrew/.linuxbrew
$ ls -ld /home
lrwxrwxrwx. 4 root root 8 Jun 29 22:29 /home -> var/home
```
I was hoping to correct `HOMEBREW_PREFIX` from the start (in `bin/brew`), but the default prefixes are in `brew.sh`. See #15656 for a discussion on this middleground solution.
Co-Authored-By: rohanssrao <17805516+rohanssrao@users.noreply.github.com>
Co-Authored-By: Bo Anderson <mail@boanderson.me>
