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>
`cleanup_path` already handles the dry-run logic, and also includes
those paths in the summary of space freed by `brew cleanup`.
Before this change:
❯ brew cleanup --dry-run
Would remove: /Users/carlocab/Library/Caches/Homebrew/bootsnap (2,401 files, 41.9MB)
After this change:
❯ brew cleanup --dry-run
Would remove: /Users/carlocab/Library/Caches/Homebrew/bootsnap (2,401 files, 41.9MB)
==> This operation would free approximately 41.9MB of disk space.
Inside a given `site-packages` directory, *.pyc files live in
`__pycache__` directories. These are created by the Python interpreter
when a module is imported in order to speed up future access to the
imported module.
These can be left behind when formulae are uninstalled, which results in
erroneous success in importing the modules they were originally compiled
for.
Let's fix that by cleaning these up. In the top-level `__pycache__`
directory, we use the `Pathname#prune?` extension in order to determine
whether a `*.pyc` file is old enough to clean up. In other directories,
we clean them up when they are all that remains in a given module's
tree.
Removing these `*.pyc` files will make `python3` regenerate them when
required, so deleting them is relatively safe. The worst consequence is
slightly slower module import times.
Closes#13701.
