Move the resetting of `MacOS.version` to an `ensure` block.
Fix the tests by adding a test OS and new fixture that has a
different version for that test OS.
Valid `strategy` block return types currently vary between
strategies. Some only accept a string whereas others accept a string
or array of strings. [`strategy` blocks also accept a `nil` return
(to simplify early returns) but this was already standardized across
strategies.]
While some strategies only identify one version by default (where a
string is an appropriate return type), it could be that a strategy
block identifies more than one version. In this situation, the
strategy would need to be modified to accept (and work with) an
array from a `strategy` block.
Rather than waiting for this to become a problem, this modifies all
strategies to standardize on allowing `strategy` blocks to return a
string or array of strings (even if only one of these is currently
used in practice). Standardizing valid return types helps to further
simplify the mental model for `strategy` blocks and reduce cognitive
load.
This commit extracts related logic from `#find_versions` into
methods like `#versions_from_content`, which is conceptually similar
to `PageMatch#page_matches` (renamed to `#versions_from_content`
for consistency). This allows us to write tests for the related code
without having to make network requests (or stub them) at this point.
In general, this also helps to better align the structure of
strategies and how the various `#find_versions` methods work with
versions.
There's still more planned work to be done here but this is a step
in the right direction.
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.
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
