This makes sense in isolation.

Though it does seem problematic when we have any dependents using it as we'll get mixed runtime Pythons again and they will now need to be migrated as one.

Alternative solutions could be:

• Introduce a shim executable that automatically picks whatever supported Python it can find in the PATH.
• Separate executables into a separate formula (perhaps tricky given we don't support subpackages)

Though it does seem problematic when we have any dependents using it as we'll get mixed runtime Pythons again and they will now need to be migrated as one.

As I recall, we ignore mixed Pythons in dependency tree (#13714) so migration should still be possible separately.

Alternative solutions could be:

• Introduce a shim executable that automatically picks whatever supported Python it can find in the PATH.

I've thought on this before but seemed like it would end up a bit hacky. Open to discussion if there is a reasonable way. However, some formulae will still be non-functional out-of-the-box unless user installs a python separately (which may require propagating caveats to impacted formulae).

• Separate executables into a separate formula (perhaps tricky given we don't support subpackages)

We've tried this before and reverted those formulae now (e.g. python-tabulate + libpython-tabulate). It often required various workarounds to support given our lack of subpackages.

As I recall, we ignore mixed Pythons in dependency tree (#13714) so migration should still be possible separately.

It's not a great user experience though for a formula to depend on two versions of Python, particularly when only one is really needed.

I'm fine with this change if it's preferred, but it does feel like there's better solutions.

It's not a great user experience though for a formula to depend on two versions of Python, particularly when only one is really needed.

Ideally, should only happen for short time during migration.

We probably should discuss/document further on Python package distribution as we don't seem to be following our original guidelines, e.g. https://docs.brew.sh/Python-for-Formula-Authors

I'm fine with this change if it's preferred, but it does feel like there's better solutions.

I am open to any other ideas. Just that during current python@3.11 --> python@3.12 migration we have impacted more formulae than previous migrations so may end up seeing more user issues.

An opposite approach would be preventing "multiple pythons" for formulae whose functionality depends on the bin scripts.

For example,

• pyinvoke workflow needs bin scripts - https://docs.pyinvoke.org/en/stable/getting-started.html#defining-and-running-task-functions (Upgrading pyinvoke to 2.2.0_1 breaks running inv if python@3.12 is not installed homebrew-core#151248)
• I think docutils also commonly uses bin scripts - https://docutils.sourceforge.io/README.html#usage

On other hand, there are some formulae that have bin scripts that are not commonly used (e.g. python-tabulate).

We probably should discuss/document further on Python package distribution as we don't seem to be following our original guidelines, e.g. https://docs.brew.sh/Python-for-Formula-Authors

If we can turn any of those guidelines into code/audits/rubocops: that would be ideal.

An opposite approach would be preventing "multiple pythons" for formulae whose functionality depends on the bin scripts.

This makes sense to me 👍🏻

Will close for now until we finalize on how we want to handle Python formulae moving forward (especially given adoption of PEP 668 in python@3.12 and other changes ongoing in homebrew-core).