We're using `formula.eligible_kegs_for_cleanup` to figure out which
formula should be kept or removed based on e.g. `brew pin` status but
we didn't use this sufficiently in `brew cleanup` to avoid cleaning up
all cached files related to a pinned keg.
Instead, let's use a (cached) call to
`formula.eligible_kegs_for_cleanup` to ensure that we check all
related resources, manifests, etc. for pinned bottles rather than just
the latest version.
- 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
```
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>
`autoremove` is destructive, and it can be difficult for users to
recover from it occuring when they weren't expecting it.
Fixes#17363FixesHomebrew/discussions#5395
This reverts commit 3d114161b3c3f1a95b94e8530f5bc45bb44bbbd9.
This reverts commit efb14a0ec264c4ef408dbbd5330905dd230e979c.
This suggests setting an environment variable that is different
than the one we end up checking so I've updated the warning so
now things match. If the goal was to have the name in the warning,
the environment variable checking logic could be updated. I have
no personal preference.
```console
$ brew irb
==> Interactive Homebrew Shell
Example commands available with: `brew irb --examples`
brew(main):001:0> ENV["HOMEBREW_NO_AUTO_REMOVE"] = "1"
=> "1"
brew(main):002:0> Homebrew::EnvConfig.no_autoremove?
=> false
brew(main):003:0> ENV["HOMEBREW_NO_AUTOREMOVE"] = "1"
=> "1"
brew(main):004:0> Homebrew::EnvConfig.no_autoremove?
=> true
```
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>
