- I found a few occurrences of this pattern from
https://github.com/orgs/Homebrew/projects/5?pane=issue&itemId=97021840,
that is an automated style request for:
`core: use / instead of + operator in e.g. (lib+"lv").install "lv.hlp"`.
- Upon adding tests I realised that there's also the `prefix + "bin"`
case that's already handled differently, so let's combine the handling
given it's the same `+` that's wrong.
Add a new RuboCop to detect the use of 0.0.0.0 in formulae which
indicates binding to all network interfaces, internally or externally,
so is a bad default and potentially a security risk.
Co-authored-by: Issy Long <me@issylong.com>
This adds support for Cask old tokens used for renames of Casks.
We'll now correctly check these at installation time to avoid repeatedly
installing renamed Casks and dump them in the Brewfile. We also use this
logic to avoid cleaning up renamed Casks.
- Homebrew Bundle referred to formulae as "brews". But it referred to
casks as "casks" and taps as "taps".
- Let's use the same terminology everywhere.
- (I know that `brew "hello"` is the formula syntax in the Brewfile, so
I'm not changing that (though would be up for it, in a backwards
compatible manner), just making the code more consistent.)
- This file was _massive_ - over 60k lines and we had to bump the file
size limit for pushes to the repo!
- This was because by default Tapioca, when it encounters a
`require "rubocop"` during RBI generation, loads all of the cops ever
because they're all classes inside `RuboCop::Cop`.
- There wasn't an easy way to control this at Tapioca generation time
(we tried), so now we parse the generated RBI file and delete classes
and method definitions that we don't use.
- I regenerated the RBIs (`brew tc --update rubocop`) and added new
things to the allowlist until Sorbet came back green.
- Now the file is ~7k lines and 240K - much better!
We have a `HOMEBREW_MACOS_NEWEST_UNSUPPORTED` environment variable
and this is used in `MacOSVersion` to determine prerelease versions
but we don't have a way of easily determining the newest supported
macOS version.
`bump-cask-pr` contains logic that assumes the first key/value in
`MacOSVersion::SYMBOLS` is the newest macOS version but it recently
became clear that this is a prerelease version between WWDC and the
subsequent macOS release. Similarly, `dev-cmd/generate-cask-api.rb`
tries to compute the newest stable macOS version as
`HOMEBREW_MACOS_NEWEST_UNSUPPORTED.to_i - 1` and this will fail
if/when we update that variable to `"26"`, as the macOS version
before 26 is 15, not 25.
This adds a `HOMEBREW_MACOS_NEWEST_SUPPORTED` environment variable,
so we have a straightforward way of quickly identifying the newest
supported macOS version without having to make potentially unreliable
assumptions or do computations to identify the latest non-prerelease
`MacOSVersion` value. This also updates the two aforementioned areas
to use this environment variable to produce the newest stable macOS
version symbol in a more reliable way.
