`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.
We have an audit that checks each formula's dependency tree for multiple
versions of the same software. We have an allowlist that allows us to
ignore this audit, but this allowlist requires each formula with a
conflict in its dependency tree to be listed there.
Here, I propose the reverse: if formula `foo` appears in the
`versioned_formula_dependent_conflicts_allowlist`, then all its
dependents will not fail the versioned dependencies conflict because of
a conflict with formula `foo`.
I'd like to do this in the case of `python`, where I think the versioned
dependencies conflict check hurts us more than helps us. Versioned
dependency conflicts are most problematic in the case of libraries with
the same install name but incompatible ABIs. This is almost never a
problem with Python: almost no formulae link with the Python framework
on macOS (in part due to one of our audits that disallows Python
framework linkage in Python modules). Moreover, the various Python
frameworks that we ship have the version in the install name.
The above _might_ be a problem on Linux, since we allow unrestricted
linkage with `libpython`. However, we don't even check versioned
conflicts on Linux, so we aren't as concerned about this in the first
place.
This is also a lot more convenient than adding the dependents of some
Python formula one by one as they acquire conflicts due to changes in
other formulae.
I've also amended `tap_auditor` to allow the use of formula aliases in
an allowlist, to allow us to add `python` to this allowlist instead of
each individual versioned Python formula.
See also discussion at Homebrew/homebrew-core#108307.
Occasionally, a new version of Rust will cause failures in dependents.
See, for example, Homebrew/homebrew-core#107818.
This change will allow us to get a fuller backtrace in CI, which will
also make it easier to submit bug reports upstream.
Without this change, recovering a full backtrace requires installing the
new version of Rust and rebuilding the failing formula from source. Both
these steps can be skipped if we set `RUST_BACKTRACE` when retrying a
failing test.
Some formulae declare multiple Python dependencies, and they can appear
in any order in the `deps` array. Let's make sure to prefer the newest
one when adding their `libexec/"bin"` directory to `PATH`.
Some formulae are flexible about the version of Python3 that they use.
However, when we use `#detected_python_shebang` on these formulae, they
become coupled to the specific version of Python3 declared in the
formula.
This is harmful because
1. it prevents us from using `uses_from_macos "python"` even in formulae
where we should be able to
2. it forces us to rebuild the formula whenever we make changes to the
Python dependency when nothing but the shebang would have changed as
a consequence of the rebuild
For an example of this, see Homebrew/homebrew-core#107905.
I'd also like to do this to get rid of some really terrible hacks we
have in `glib-utils` as a means of decoupling `glib` from the specific
versioned Python dependency it used to have.
See Homebrew/homebrew-core#103916, or Homebrew/homebrew-core#106045 for
a proposal to give the same treatment to `gobject-introspection`.
