• Any recursive dependent of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

This currently includes all Python dependents, no? Though I suppose we want to and should fix that.

• Any recursive dependent of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

This currently includes all Python dependents, no? Though I suppose we want to and should fix that.

All Python dependencies.

python@3.12 ended up being a dependency of LLVM anyway so we have already built that depedency tree.

• Any recursive dependent of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

This currently includes all Python dependents, no? Though I suppose we want to and should fix that.

All Python dependencies.

So, should the original post instead say

• Any recursive dependency of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

? (Or am I confused?)

If you are building e.g. mpdecimal, a Python dependency, you need to check dependents to find Python.

(btw I've also added a note about --all-supported to the original issue as I forgot about that case)

Alternatively: you could find all formula matching pour_bottle_only_if, calculate their dependency trees, union into one and then check for intersections between that list and the tested formulae.

Might be computationally cheaper given you don't need to check every dependency tree though haven't tried it out.

• --all-supported is passed

What is this for/to do?

• Any recursive dependent of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

Could this be non-recursive?

Feels like adding a new DSL for this might be nicer and a bit less involved?

If you are building e.g. mpdecimal, a Python dependency, you need to check dependents to find Python.

Ah, gotcha, thanks for the explanation.

What is this for/to do?

Cache workflow + brew doctor workflow here.

Could this be non-recursive?

No, we build full dependency trees. For the affected formulae this isn't that big if we maybe flip it and check the dependency trees rather than constructing dependent trees.

Feels like adding a new DSL for this might be nicer and a bit less involved?

The DSL is effectively there for most cases except the pkg-config exception. We just need it to cover the full dep tree.

• Any recursive dependent of the tested formula satisfies dependent_formula.class.pour_bottle_only_if == :clt_installed

This is pretty straightforward to do now with TestRunnerFormula#dependents.

Though the implementation of that is really inefficient -- it walks Formula.all for each runner and tested formula. This is part of why it's really slow, but the slowness didn't matter as much previously (since it could run concurrently with formula builds).

Ideally it would construct the dependency tree once for each runner and then query that for each tested formula instead.

We can probably walk through it once to fetch the pour_bottle formulae (which we can likely assume isn't OS-specific) and then only construct the dependency trees for those formulae.

What is this for/to do?

Cache workflow + brew doctor workflow here.

Ok, gotcha.

For the affected formulae this isn't that big if we maybe flip it and check the dependency trees rather than constructing dependent trees.

This seems nicer.

The DSL is effectively there for most cases except the pkg-config exception. We just need it to cover the full dep tree.

I think it's kind of there but very unintuitive to folks without a deep understanding of Homebrew and/or macOS SDKs.

I think a new DSL with audits or cops to enforce them based on the cases we already know would be nice rather than an implied DSL like we have today.