- 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!
```
Logically new formulas should start at revision 0, but a
developer might use an existing formula as a template and
otherwise not realize they should remove this field.
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
Since the `fish_add_path` command modifies a universal Fish variable
(which is automatically persisted to a file) it's unnecessary to run it
again every time a new shell is opened.
This is causing failures when attempting to rewrite shebangs during the
cleanup stage of `brew install`.
See, for example, Homebrew/homebrew-core#94323,
Homebrew/homebrew-core#94321.
This reverts commit 7e6be5eb4474ed9eaa4b8e9a5a45e3340186840c.
This currently no longer applies, because we might sometimes need an
older `setuptools` than the one shipped with a Python formula.
This is needed for Homebrew/homebrew-core#93964.
When building Rust packages that provide libraries but no executable
binaries, `cargo install` doesn't do anything; you need to use `cargo
build` and install any libraries manually. See e.g.
rust-lang/cargo#8294.
Unfortunately, Homebrew's Rubocop "use cargo install *std_cargo_args"
rule, as currently written, blocks all invocations of `cargo build`.
This commit changes that rule to exclude invocations of `cargo build`
that use the `--lib` argument (`--lib` specifies to Cargo that a
package's library targets should be built). This will enable library
packages to be built while retaining the "use cargo install
*std_cargo_args" message for the more common case when a Rust package
provides executable binaries.
