- Previously I thought that comments were fine to discourage people from
wasting their time trying to bump things that used `undef` that Sorbet
didn't support. But RuboCop is better at this since it'll complain if
the comments are unnecessary.
- Suggested in https://github.com/Homebrew/brew/pull/18018#issuecomment-2283369501.
- I've gone for a mixture of `rubocop:disable` for the files that can't
be `typed: strict` (use of undef, required before everything else, etc)
and `rubocop:todo` for everything else that should be tried to make
strictly typed. There's no functional difference between the two as
`rubocop:todo` is `rubocop:disable` with a different name.
- And I entirely disabled the cop for the docs/ directory since
`typed: strict` isn't going to gain us anything for some Markdown
linting config files.
- This means that now it's easier to track what needs to be done rather
than relying on checklists of files in our big Sorbet issue:
```shell
$ git grep 'typed: true # rubocop:todo Sorbet/StrictSigil' | wc -l
268
```
- And this is confirmed working for new files:
```shell
$ git status
On branch use-rubocop-for-sorbet-strict-sigils
Untracked files:
(use "git add <file>..." to include in what will be committed)
Library/Homebrew/bad.rb
Library/Homebrew/good.rb
nothing added to commit but untracked files present (use "git add" to track)
$ brew style
Offenses:
bad.rb:1:1: C: Sorbet/StrictSigil: Sorbet sigil should be at least strict got true.
^^^^^^^^^^^^^
1340 files inspected, 1 offense detected
```
`millions_match.captures.first` will typically be a decimal (since it's
matched using `\d+\.\d+`), except we lose accuracy in the `#to_i`
conversion.
Before:
```
❯ brew info --analytics --github-packages-downloads sqlite
==> Analytics
==> install (30 days)
[snip]
==> GitHub Packages Downloads
1,009,898 (30 days)
```
After:
```
❯ brew info --analytics --github-packages-downloads sqlite
==> Analytics
==> install (30 days)
[snip]
==> GitHub Packages Downloads
1,199,898 (30 days)
```
In this case `1.19M` was being rounded down to `1M`.
My experience recently playing around with our locking behaviour is
that, while mostly seamless and not seen by users, it's leaks
implementation details a bit too heavily.
As a result, the following improvements are in this commit:
- Ensure that, whenever possible, we tell the user the actual command
that is holding a given lock instead of the lock name (an internal
implementation detail)
- Make the locking error output a little more consistent and user
friendly
- Add a `DownloadLock` class to simplify locking downloads
- Add a `HOMEBREW_LOCK_CONTEXT` variable to allow adding additional
context for logging error messages
- Lock paths and leave deciding how this translates to lock names up
to the locking code itself
- Lock the Cellar/Caskroom paths explicitly rather than implicitly
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Per feedback to https://github.com/Homebrew/brew/pull/17806, this
moves some `require` statements in `dev-cmd/contributions.rb` and
`Utils::GitHub` into the methods that need them.
This resolves `unitialized constant` errors in `brew contributions`
(`Tap`, `GitHub`) and `Utils::GitHub` (`Utils::Curl`).
This also preemptively adds some requires to `Utils::GitHub` and
`GitHub::API`, to avoid similar errors.
This is primarily intended to resolve the `uninitialized constant
Utils::Backtrace` error in `formula_versions.rb:60` but I expanded it
to try to cover all existing usage of `Utils::Backtrace`.
I've followed the existing pattern, where `utils/backtrace` is
required in the context of where it's used. Many of these cases use
`Backtrace` in a conditional manner, so I've tried to ensure that the
`require` follows suit.
We've filter this out in `brew formula-analytics` too but let's avoid
sending it here in the first place so we can delete the
formula-analytics filtering later.
Take 2 of https://github.com/Homebrew/brew/pull/17692 but with:
- provide and document `HOMEBREW_NO_VERIFY_ATTESTATIONS`
- don't try to run unless there's GitHub credentials
- don't try to run unless `gh` is installed
- don't try to run in CI
While we're here:
- split out a `Homebrew::EnvConfig.devcmdrun?` helper method
- add some missing `Homebrew::EnvConfig.github_api_token` presence
checks
This improves the load time of most brew commands. For an example of
one of the simplest commands this speeds up:
Without Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 525.0 ms ± 35.8 ms [User: 229.9 ms, System: 113.1 ms]
Range (min … max): 465.3 ms … 576.6 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 383.3 ms ± 25.1 ms [User: 133.0 ms, System: 72.1 ms]
Range (min … max): 353.0 ms … 443.6 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.37 ± 0.13 times faster than git checkout master; brew help
```
With Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 386.0 ms ± 30.9 ms [User: 130.2 ms, System: 93.8 ms]
Range (min … max): 359.5 ms … 469.3 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 330.2 ms ± 32.4 ms [User: 93.4 ms, System: 73.0 ms]
Range (min … max): 302.9 ms … 413.9 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.17 ± 0.15 times faster than git checkout master; brew help
```
When a formula was built from source, it should not be removed by
`brew autoremove` as it will take a while to be installed again.
Fixes https://github.com/Homebrew/brew/issues/17433
- Use the `HOMEBREW_PORTABLE_RUBY_VERSION` environment variable to
determine the version of the Portable Ruby to use in
`vendor-install.sh` and `ruby.sh`.
- Replace the `docs/.ruby-version` file with a symlink to
`Library/Homebrew/.ruby-version`.
- Fix an incorrect `HOMEBREW_LIBRARY` comment.
- Use a simpler `HOMEBREW_USING_PORTABLE_RUBY` definition.
