BuildPulse is trying to find flaky tests for us but, given the previous
model of using `rspec-retry`, it would rarely find them. Instead, let's
try to always rerun `brew tests` multiple times, report to BuildPulse
each time (by moving the reporting logic into `brew tests`) and disable
`rspec-retry` when using BuildPulse.
While we're here, let's enable `rspec-retry` locally so we don't have
flaky tests biting maintainers/contributors there.
A user may wish to use two use two brew-installed Python packages
together. For example, one might want to `import numpy` when using
`jupyterlab` or `ptpython`.
Currently, the only ways to do this I'm aware of is with some hacking of
`PYTHONPATH` or the creation of `.pth` files in a formula's prefix.
A better solution is to allow the virtualenvs that `brew` creates to
have access to system site-packages by default, so that `import numpy`
inside `ptpython` or `jupyterlab` just works.
Partially resolvesHomebrew/homebrew-core#76950.
Arch-specific build tool formulae (https://github.com/Homebrew/homebrew-core/pull/79874) install their info files in `#{info}/<arch>` to avoid conflicts with the main tool formulae.
However, the info cleaner only removes `#{info}/dir`, so each tool's bottle includes `#{info}/<arch>/dir`, which causes install-time conflicts.
This PR fixes that by deleting all `dir`s under `#{info}`.
Before:
```
==> Cleaning
[...]
==> Fixing /usr/local/Cellar/i686-elf-binutils/2.36.1_1/lib/i686-elf/bfd-plugins/libdep.so permissions from 755 to 444
==> Finishing up
```
After:
```
==> Cleaning
[...]
==> Fixing /usr/local/Cellar/i686-elf-binutils/2.36.1_1/lib/i686-elf/bfd-plugins/libdep.so permissions from 755 to 444
rm /usr/local/Cellar/i686-elf-binutils/2.36.1_1/share/info/i686-elf/dir
==> Finishing up
```
Currently, we copy `config.log` and `CMakeCache.txt` from the root of
the source tree into the the logs generated by the build. This has three
shortcomings:
1. These files are not necessarily found where we look. This is often
the case with a CMake build, but can occur with an Autotools build
as well (e.g. GCC, or any other out-of-tree build).
2. There may be several of these files scattered throughout the build
tree. This occurs, for example, when the build itself invokes
`configure` or `cmake` as part of the build process.
3. We don't copy `CMakeOutput.log` or `CMakeError.log`, which are
usually more informative about what happened during the CMake
invocation. It is not sufficient to add them to the array of log
files that we copy because these are never found at the source root,
even when building in-tree.
Let's rectify this by copying all instances of these files that can be
found in the source tree. Since there will inevitably be duplicate file
names, we also store them in the log directory using the same relative
paths from the source root. [1] This has the added benefit of providing
context for these log files.
[1] For example, if `CMakeOutput.log` can be found in `build/CMakeFiles`
relative to the source root, then that will also be where it will be
stored in the log directory.
