brew create --python should exclude some resources and replace some with formulae

[activescott]

Provide a detailed description of the proposed feature

Running brew create --python adds multiple resource... entries based on the python package that I've learned in code reviews of a PR should in fact be excluded (e.g. wheel) or replaced with a corresponding Homebrew formulae instead.

What is the motivation for the feature?

There are a number of examples in a recent usage of python create --python for homebrew/homebrew-core#104096 and

I've attempted to catalog them below:

• exclude resource "wheel": @carlocab wrote ...I thought brew excludes wheel automatically at https://github.com/Homebrew/homebrew-core/pull/104096#discussion_r913640569
• replace six with depends_on "six": @SMillerDev wrote This can be replaced by `depends_on "six" at https://github.com/Homebrew/homebrew-core/pull/104096#discussion_r902317849_
• replace resource "Cython" with depends_on "cython": Supported by reviewers at https://github.com/Homebrew/homebrew-core/pull/104096#discussion_r913574384
• replace resource "docutils" with depends_on "docutils"?: Per suggestion at https://github.com/Homebrew/homebrew-core/pull/104096#discussion_r913640134

How will the feature be relevant to at least 90% of Homebrew users?

It will make it easier for formula creators to create correct formulae from python packages.

What alternatives to the feature have been considered?

Potential alternatives that I can think of:

• Simple check with grep in github actions workflow for new formulas?
• Add checks in brew audit (and ensure that it either does run as part of github action workflow, or add it as a separate step there)

[MikeMcQuaid]

@carlocab @SMillerDev does this seem sensible/reasonable to you?

[carlocab]

Yes. Better handling of this in brew is actually something I've wanted for some time now.

[SMillerDev]

It makes sense to me for update-python-resources to prefer formulae. Not all of these suggestions turned out to work though so we can't do exclude if name == some_formula_name

[apainintheneck]

I took a little look at this and I'm not sure that we can really automate this. Are there any general rules around always excluding certain resources or replacing them with their formula equivalents?

For example, the wheel resource seems to be unnecessary for some formulas but not all. It is currently used by 14 formulas in Homebrew/Core.

$ grep -l 'resource "wheel"' *.rb
bzt.rb
charm-tools.rb
fdroidserver.rb
keepkey-agent.rb
magic-wormhole.rb
pdm.rb
pip-tools.rb
pipgrip.rb
[email protected]
[email protected]
[email protected]
[email protected]
statik.rb
trezor-agent.rb

Or another example is the Cython resource mentioned above. We weren't able to replace it with the identically named cython formula; libcython needed to be used instead.

It seems like we'd need to maintain an explicit list of resources that can be either ignored or replaced with other formula and I'm just not sure if that's worth it. How much effort would be saved by such a list and how much effort would have to go into maintaining it going forward?

[carlocab]

For example, the wheel resource seems to be unnecessary for some formulas but not all. It is currently used by 14 formulas in Homebrew/Core.

I think those formulae should no longer need a wheel resource, actually. IIRC (I may not be!), there was some issue with the wheel that we bundled with the relevant python@* formula at the time. That's likely fixed now.

Or another example is the Cython resource mentioned above. We weren't able to replace it with the identically named cython formula; libcython needed to be used instead.

We should get rid of libcython and libpython-tabulate -- those were split in order to avoid the conflicting versioned dependencies audit. Python will now not trigger this audit anymore, so we can just have a cython and python-tabulate instead. These formulae can still ship Python libraries for older versions of Python if needed.

[MikeMcQuaid]

Passing on this. We'll review a PR but not going to leave it open indefinitely, sorry!