Refine ask‐option dependency resolution and strengthen tests

[tyuwags]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

These changes resolve an error a finding the whole hierarchy for the ask option, pruning the build dependencies and be able to find the whole dependants hierarchy of the formula.
These changes also create and update tests to make sure the whole hierarchy is displayed in the ask prompt.

[tyuwags]

I saw a problem, with this example, I don't know if it's the expected behaviour.
Here the deps of fonttools
fonttools
└── python@3.13
├── mpdecimal
├── openssl@3
│ └── ca-certificates
├── sqlite
│ └── readline
├── xz
└── expat
Fonttools and sqlite are outdated but not python@3.13
My function found correctly that if I do brew upgrade --ask fonttools that fonttools and sqlite need to be upgraded as I look into the recursive dependencies.
But as python@3.13 is up-to-date, sqlite isn't upgraded by brew, I don't know if it's a normal behaviour and I should modify my function in consequence or if I should open an issue for the upgrade function.

[MikeMcQuaid]

look into the recursive dependencies.
But as python@3.13 is up-to-date, sqlite isn't upgraded by brew, I don't know if it's a normal behaviour and I should modify my function in consequence or if I should open an issue for the upgrade function.

@tyuwags Not sure I understand the question. It's expected that some dependencies may need to be upgraded and others may not. Does that answer your question?

[tyuwags]

Thanks for the reply! Let me clarify the issue a bit:

In this example:

• fonttools is outdated
• sqlite is also outdated, and it's a dependency of python@3.13
• python@3.13 itself is not outdated
  When I run brew upgrade --ask fonttools, my function detects both fonttools and sqlite as outdated by looking through recursive dependencies — which seems logical.

However, during the actual upgrade, Homebrew skips sqlite because its direct parent (python@3.13) is not being rebuilt.

So my actual question is:

Should my function consider only the outdated recursive dependencies whose parent will also be rebuilt?
Or is it fine (or even expected) that brew upgrade skips outdated indirect deps when their parent is not being upgraded?
I'm trying to align my implementation logic with how brew upgrade behaves internally. Thanks again!

[MikeMcQuaid]

Or is it fine (or even expected) that brew upgrade skips outdated indirect deps when their parent is not being upgraded?

This is expected.

I'm trying to align my implementation logic with how brew upgrade behaves internally.

Thanks for this. Ideally this would be done by using the same code rather than having two code paths that have to mirror each other.

[tyuwags]

Thanks for this. Ideally this would be done by using the same code rather than having two code paths that have to mirror each other.

That was my initial thought as well. However, from what I’ve seen, brew doesn’t seem to know upfront which formulae will need to be upgraded. Instead, it determines the necessary dependencies and dependents dynamically using:

Upgrade.upgrade_formulae formulae_to_install
Upgrade.check_installed_dependents formulae_to_install

What I'd like is for these functions to return the full list of formulae that need to be upgraded, without performing the upgrade yet. Then, I could pass that list to a separate function that handles the actual upgrade logic.

This way, I could reuse the existing resolution logic and keep everything consistent, without duplicating or mirroring code paths.

[MikeMcQuaid]

@tyuwags I'm open to seeing PR(s) to modify those functions to the logic can be shared. Let me know when this one is ready for review and maybe make it draft until then?

[tyuwags]

@MikeMcQuaid, everything is ready, everything is resolved

[MikeMcQuaid]

A few suggested style tweaks but the bulk of this looks great, thanks @tyuwags! Feel like we're really close now. Gonna ask a few other maintainers to review.

[Bo98]

Looks good overall. Mostly some naming comments here, though with a couple of logic comments at the end which are more important.

[MikeMcQuaid]

Thanks @tyuwags!