I am removing `glib-utils` in (1) Homebrew/homebrew-core#108307, and all
`glib-utils` dependencies in (2) Homebrew/homebrew-core#108497.
This audit prevents me from proceeding with (1) without rebuilding all
the formulae modified in (2). I don't think that is needed, so I'd like
to exempt `glib-utils` from the rename audit instead.
To give you a clearer idea of how I plan to do this, this is the order
of events:
1. Merge this change.
2. Merge Homebrew/homebrew-core#108307.
3. Merge Homebrew/homebrew-core#108497.
4. Revert this change.
This should allow us to get rid of `glib-utils` and its accompanying
hacks without having to rebuild dozens of formulae needlessly.
There are about 10 formulae which need a bit more flexibility from
`#rpath`. Most of them use `Pathname#relative_path_from`, so we can
replace those instances with a call to `#rpath` instead once `#rpath`
knows how to handle this.
`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.
