- Rename use of "preinstall" to "auto update". The original "preinstall"
naming came from the fact that we used to only auto-update before
`brew install` but now that it's many commands: this is more confusing
than useful.
- Add `HOMEBREW_NO_UPDATE_REPORT_ONLY_INSTALLED` and remove
`HOMEBREW_UPDATE_REPORT_ONLY_INSTALLED`; the latter is now the default
and the prior provides an opt-out for better output, performance and
avoiding reading potentially untrusted formulae.
- Add `HOMEBREW_UPDATE_FORMULA_VERSION_CHECKS` and don't check formula
versions by default for better performance by default.
Co-authored-by: Eric Knibbe <3324775+EricFromCanada@users.noreply.github.com>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
Current situation with update.sh & update-reset.sh:
Upon creating a new tap and before adding remote 'origin' to it,
running `brew update` produces multiple cryptic error messages.
This change converts these cryptic Git messages into clear warnings
about absent remote 'origin'.
How to test:
1. Create a new tap using `brew tap-new`
2. Run `brew update`
- The `brew uninstall` command has `--zap`, so let's make `brew
reinstall` have parity here for a better user experience. (Requested
in issue 12983.)
- It feels weird that to get my new reinstall test to pass I had to add
`--zap` to `cask/cmd/install.rb`, not `cask/cmd/reinstall.rb` to get
the tests to pass. But the `brew reinstall --cask caffeine --zap`
command worked fine all the time. The CLI argument parser from the
test run was complaining about not knowing what `zap` was. As a
result, `--zap` now shows up as a switch in `brew install --help`
which I'm not 100% convinced is the desired UX. But I've edited the
description accordingly to specify that it will only work on
`reinstall` operations (and `--zap` on `install` is a no-op).
```
issyl0 at pictor in /opt/homebrew on reinstall-cask-zap
❯ brew reinstall --cask caffeine --zap
==> Downloading https://github.com/IntelliScape/caffeine/releases/download/1.1.3/Caffeine.dmg
Already downloaded: /Users/issyl0/Library/Caches/Homebrew/downloads/3d6ccfdd3b8d0ab37d1c2468d6e69078c2d31d3b12bf51947c4db21e5f376af2--Caffeine.dmg
==> Implied `brew uninstall --cask caffeine`
==> Backing App 'Caffeine.app' up to '/opt/homebrew/Caskroom/caffeine/1.1.3/Caffeine.app'
==> Removing App '/Applications/Caffeine.app'
==> Dispatching zap stanza
==> Trashing files:
~/Library/Application Support/com.intelliscapesolutions.caffeine
~/Library/Preferences/com.intelliscapesolutions.caffeine.plist
~/Library/Caches/com.intelliscapesolutions.caffeine
~/Library/HTTPStoages/com.intelliscapesolutions.caffeine.binarycookies
==> Removing all staged versions of Cask 'caffeine'
==> Installing Cask caffeine
==> Moving App 'Caffeine.app' to '/Applications/Caffeine.app'
🍺 caffeine was successfully installed!
```
Add a new method for the two places we're checking if we have any
casks installed. This is much more performance and user friendly than
attempting to load every cask.
Fixes#13027
Add some `--all` flags we'll eventually migrate to to ensure that we'll
eventually require their usage to read all formulae. Where we need to
do stuff later, add some comments.
Allows you to avoid the `Keg::ConflictError` recommending that you invoke `brew link --overwrite` in scenarios when you know that that's how you'd proceed anyway.
Some setups (e.g. a default `tmux` session) will result in a user
starting multiple nested login shells. This is a problem for the way we
currently handle `shellenv` because a login shell invokes
`/usr/libexec/path_helper` which will prepend the contents of
`/etc/paths` and `/etc/paths.d` to `PATH`. In particular, the second
login shell will place `brew` further down the `PATH` than desired in a
non-`/usr/local` prefix, since `brew shellenv` will no longer produce
output the second time around.
Let's fix this by replacing the check that `brew` is in `PATH` with a
check that `${HOMEBREW_PREFIX}/bin` precedes `/usr/bin` in `PATH`.
Fixes#11851, #11883, Homebrew/discussions#2547.
See also:
- Homebrew/discussions#2237
- https://superuser.com/questions/544989/does-tmux-sort-the-path-variable
There's a few bits of functionality that Homebrew has changed over the
years, makes sense as a sensible default but some people find really
annoying:
- automatically running `brew update`
- automatically running `brew cleanup`
- automatically upgrading outdated dependents
- automatically reinstalling broken dependents
For each of these: let's improve the documentation of the commands
whose behaviour is changed and the environment variables themselves.
