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.
In preparation for detecting flaky tests with BuildPulse, this commit
sets up the rspec_junit_formatter gem to output JUnit XML reports of the
test suite, which is the format used by BuildPulse and various other
tooling that interprets test results.
Because the test suite uses the parallel_tests gem, this commit
incorporates some related changes to make all the parallel_tests gem and
the rspec_junit_formatter gem to cooperate with each other.
rspec_junit_formatter writes everything to a single XML file. That works
fine when there's only one process writing to the file. By default,
whatever process finishes last will write to the file and clobber the
output of all the other processes that wrote to the file. 🙈
To prevent this issue, the parallel_tests wiki recommends adding a
`.rspec_parallel` file to specify its RSpec options
(https://github.com/grosser/parallel_tests/wiki#with-rspec_junit_formatter----by-jgarber),
then the project can specify different files for each process to write
to like so:
--format RspecJunitFormatter
--out tmp/rspec<%= ENV['TEST_ENV_NUMBER'] %>.xml
However, prior to this commit, the Homebrew/brew test suite specified
its RSpec options via the command line. Unfortunately though, there's no
way (AFAICT) to set the equivalent of these options via the command
line:
--format RspecJunitFormatter
--out tmp/rspec<%= ENV['TEST_ENV_NUMBER'] %>.xml
So, we need to use a `.rspec_parallel` file to specify these options ☝️.
However, it appears that RSpec allows you to specify formatters _either_
in an options file (like `.rspec_parallel`) _or_ via command-line args.
But if you specify any formatters via command-line args, then all
formatters in the options file are ignored. (I suspect that's somehow
related to this bit of code in rspec-core:
https://github.com/rspec/rspec-core/blob/v3.10.0/lib/rspec/core/configuration_options.rb#L64.)
With that in mind, in order to have the RspecJunitFormatter configured
in `.rspec_parallel`, we need to move the other formatters into
`.rpsec_parallel` as well, instead of passing them as command-line
args. Therefore, this commit moves all the formatters into a
`.rspec_parallel` file.
This was failing for me locally so I've made some fixes:
- remove the `markdown` flag (as it's the only path now)
- refactor the generation to not use intermediate variables
- discard more weird cases rather than erroring
- exclude @Homebrew changes (e.g. from bots) because we don't care about
these in the release notes
