These are regression tests to make sure that this logic is reproducible.
If this logic is not working, it might mean that someone removes a tap
accidentally that still includes a formula or cask that they currently
have installed.
The tests are extravagant and over-engineered but I'm not sure that
there's an easier way to do this without massive integration tests.
This wasn't working before for a few reasons.
1. It never got past the installed name check because the
installed name sets had short names and the tap names were
long names including the tap namespace too. Now we just trim the
long name before comparing it to the installed name set.
Before:
```
["name"].include?("tap/full/name") # always false
```
After:
```
["name"].include("tap/full/name".split("/").last) # sometimes true
```
2. The names we were trying to load formulae and casks with
were incorrect.
Before:
```
tap = Tap.fetch("homebrew/cask-versions")
token = "homebrew/cask-versions/token"
cask = Cask::CaskLoader.load("#{tap}/#{token}")
```
After:
```
token = "homebrew/cask-versions/token"
cask = CaskCaskLoader.load(token)
```
This allows dry-run to display any directories that will be removed
as a result of previous removal steps.
Signed-off-by: Michael Cho <michael@michaelcho.dev>
It was possible for the cask tokens to be included twice in the
cask_tokens array. This was cancelled out by the fact that we |=
the arrays together but still it was unnecessary work that is best
avoided and makes the code harder to reason about. This is simpler.
This seems to be a bug with how we handle name shortening for the
core cask tap. The core tap always returns short formula names
and returning long names from the core cask tap when not using
the API leads to unexpected behavior.
Specifically this can trick the `brew untap` command into thinking
that there aren't any installed casks in the core cask tap and that
it can be removed even when that is not the case.
One risk here is that the full names were used when caching
descriptions so descriptions could be out of date for people in
the short term though hopefully that's not the end of the world.
I added two new methods to cache both installed and all taps.
All taps includes core taps no matter if they're installed locally
since they're always provided by the API anyway.
This makes it easier to cache `Tap.each` while making the code
easier to reason about. It also will be useful because we'll
be able to avoid the `Tap.select(&:installed?` pattern that has
recently invaded the codebase.
Note: I also stopped clearing all tap instance caches before
tests. Running `Tap.each` would cache existing taps which would
lead to unexpected behavior since the only existing tap before
each test is the core tap. This is the only tap whose directory
is not cleaned up between tests so we just clear it's cache directly.
We also now clear all tap instances after tests as well regardless
of whether the API was used that time.
- 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 adds a new file to the output of `brew generate-cask-api` which
represents the new internal JSON v3 file. It involves removing
a bunch of unneeded hash keys while removing blank ones as well.
I've made some slight changes to the cask loader as well but more
might be necessary before this starts loading things correctly.
The full loader code will be added in a separate PR.
`FormulaInstaller` already supports this (https://github.com/Homebrew/brew/pull/12691) but I didn't wire it up via `brew upgrade` and the two can be used largely interchangeably
As-of 3.1: this mean that you omit the hash value if the name is the
same as the key.
We're allowing this already and it didn't make sense to land until the
bulk of the other RuboCop 3.1 changes did but, now we're ready, it is
more concise and a pattern that people will need to understand anyway.
We have plans to add analytics for commands and `brew test-bot`
This requires a certain amount of refactoring which I've done here.
There was also a bunch of legacy `*_influx_?` usage from when we used
both InfluxDB and Google Analytics that made sense to clean up and
excessive indirection.
