Formulae bumped to python@3.13 but still depend on python@3.12 until reinstalled

[injust]

Output of brew config

HOMEBREW_VERSION: 4.4.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: e78a0adb4f260913fffdc956cc8c20fb54109feb
Last commit: 17 hours ago
Branch: stable
Core tap JSON: 26 Nov 10:49 UTC
Core cask tap JSON: 26 Nov 10:49 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: micro
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.3.6 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.6/bin/ruby
CPU: octa-core 64-bit kabylake
Clang: 16.0.0 build 1600
Git: 2.47.0 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.1.1-x86_64
CLT: 16.1.0.0.1.1729049160
Xcode: N/A

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Putting non-prefixed findutils in your path can cause python builds to fail.
^[[A
Warning: Homebrew's "sbin" was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting your PATH for example like so:
  fish_add_path /usr/local/sbin

Description of issue

Several formulae installed on my system purportedly depend on python@3.13, but they actually depend on python@3.12.

$ brew upgrade asciinema
Warning: asciinema 2.4.0 already installed

$ brew info asciinema
==> asciinema: stable 2.4.0 (bottled), HEAD
Record and share terminal sessions
https://asciinema.org
Installed
/usr/local/Cellar/asciinema/2.4.0 (79 files, 406.5KB) *
  Poured from bottle using the formulae.brew.sh API on 2024-07-10 at 12:32:36
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/a/asciinema.rb
License: GPL-3.0-only
==> Dependencies
Required: python@3.13 ✔
==> Options
--HEAD
        Install HEAD version
==> Analytics
install: 541 (30 days), 1,489 (90 days), 8,396 (365 days)
install-on-request: 541 (30 days), 1,488 (90 days), 8,392 (365 days)
build-error: 1 (30 days)

$ brew uninstall python@3.12
Error: Refusing to uninstall /usr/local/Cellar/python@3.12/3.12.7_1
because it is required by asciinema, [truncated], which are currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies python@3.12

$ ls /usr/local/opt/asciinema/libexec/bin/
asciinema
python -> ../../../../../opt/python@3.12/Frameworks/Python.framework/Versions/3.12/bin/python3.12
python3 -> ../../../../../opt/python@3.12/Frameworks/Python.framework/Versions/3.12/bin/python3.12
python3.12 -> ../../../../../opt/python@3.12/Frameworks/Python.framework/Versions/3.12/bin/python3.12

I managed to resolve this by brew reinstalling the affected formulae.

[gromgit]

@Homebrew/maintainers can probably shed more light, but IIRC, brew upgrade doesn't handle bottle rebuilds (which is what happened with the mass migration to Python 3.13), only version/revision bumps. brew reinstall OTOH just blindly reinstalls, because that's what you told it to.

[injust]

I see, that makes sense. I'll wait for others to shed some light here, but perhaps a mass migration like Python 3.13 should trigger a version bump?

[gromgit]

That tends to upset a lot of people, as a simple brew upgrade suddenly pulls down tens or even hundreds of Python formulae at one go, for no good reason other than "we bumped the dependent Python to 3.13, but nothing's actually changed under the hood for all these formulae."

The way brew upgrade works now, you'll simply have two Python versions installed, each of them having its own dependents. Then as each formula gets a new version/revision, the newer Python gets one more "convert", while the older one loses one. Finally, when the older version's dependent count goes to zero, it gets auto-removed. This is far less alarming for the typical user than a BIG BANG "upgrade" that really isn't an upgrade.

[injust]

Makes sense, thanks for explaining!

[p-linnane]

Best explanation I've seen for how we handle this. Thanks as always @gromgit!