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`.
Due to limitations of the test framework, this only tests
that the command with the --debug-symbols
flag succeeds and that on MacOS the `dsymutil` is run.
On MacOS, the compile flags `-g` are not set, and I can't figure out
how to set them here. `dsymutil` runs successfully regardless of if
there are debug symbols or not.
Same on linux therefore the test cannot succeed.
When Homebrew/homebrew-core#107517 is merged, builds will no longer be
able to find `python@3.9` as `python3`. This is also what is likely to
happen to `python@3.10` when we add a `python@3.11`.
This is likely to break many builds, so let's make sure they can keep
finding a `python3` for formulae that don't have a dependency on the
latest Python3.
This is arguably something we should've done earlier: it also means that
builds that go looking for an unversioned `python` end up finding our
Python3 (whenever present in the build environment) instead of, say,
`/usr/bin/python` which is typically Python2.
