We sometimes see errors like "attempted to use a `Downloadable`
without a URL!" in the homebrew/cask autobump workflow log because
`bump-cask-pr` can simulate Linux even if a cask doesn't support it,
leading to this error. This is something that should be resolved in
the future once I finally wrap up my related work to detect OS/arch
requirements but this adds a simple guard to address this in the
interim time.
`ensure_formula_installed!` requires the `Formula` class to be loaded
before being called to work properly.
Let's guarantee that instead by implementing it as an instance method of
the `Formula` class.
See discussion at #20358.
This does the same as #20356 for `ensure_formula_installed!`. See
discussion at #20352.
Unfortunately, one must still `require "formula"` before using this
method because of the `returns(Formula)`, but tightening the type
signature is generally a good idea anyway.
Closes#20352.
Fixes
❯ HOMEBREW_BAT=1 brew cat xz
Error: uninitialized constant Kernel::Formula
Warning: Removed Sorbet lines from backtrace!
Rerun with `--verbose` to see the original backtrace
/opt/homebrew/Library/Homebrew/extend/kernel.rb:445:in 'block in <module:Kernel>'
/opt/homebrew/Library/Homebrew/dev-cmd/cat.rb:33:in 'block in Homebrew::DevCmd::Cat#run'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/lib/ruby/3.4.0/fileutils.rb:241:in 'Dir.chdir'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/lib/ruby/3.4.0/fileutils.rb:241:in 'FileUtils#cd'
/opt/homebrew/Library/Homebrew/dev-cmd/cat.rb:29:in 'Homebrew::DevCmd::Cat#run'
/opt/homebrew/Library/Homebrew/brew.rb:113:in '<main>'
Please report this issue:
https://docs.brew.sh/Troubleshooting
This is really only used in Homebrew/core, so it should be safe to just
change `ref` here to `main`. Without this, `dispatch-build-bottle`
creates PRs that mistakenly target the `master` branch instead of the
`main` branch.
- 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!
I bailed before going all the way to `typed: strict` but this should at
least improve things and fix:
`Library/Homebrew/tab.rb:111: warning: The class Tab reached 8 shape variations, instance variables accesses will be slower and memory usage increased.`
This is the pattern we've been adopting for a while and it's a bit
cleaner. Let's remove all of the existing usage of the existing pattern
to avoid confusion when adopting the new one.
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.
I previously added some instance variables in `Cask::DSL` to its
`initialize` method but I missed some last time, so we still see
warnings like `The class Cask::DSL reached 8 shape variations,
instance variables accesses will be slower and memory usage increased.
It is recommended to define instance variables in a consistent order,
for instance by eagerly defining them all in the #initialize method.`
This initializes more instance variables in `Cask` classes to resolve
other situations where this warning may occur. I've been testing this
for a while and haven't see any warnings with these changes but
there's always a chance that there's still more work to be done.
