Formalise criteria for feature inclusion in formulae
What were you proposing (and why)?
Formalise a policy on what features can be included in formulae (when is this fine, what dependencies would we want to avoid and why, etc.). This is a tracking issue to facilitate discussion and improve our documentation on what "extra" features we are generally okay with including, and when it is fine to do so – what's the minimum number of requests beyond which we include things, etc.
A clearly documented policy allows us to point users making feature requests to it, and also ensures standards are applied consistently across formulae and by all maintainers.
Great idea 👏🏻
My take:
- we should have a (minimal) algorithm for this e.g. a number of requests that exceeds the number of (recursive) dependencies this would add
- we should consider having some
${FORMULA}-full/${FORMULA}-minimalformulae for maximal/minimal cases of formula and keep${FORMULA}for "the functionality that we need for dependencies in Homebrew itself". This would likely help make e.g.ffmpegsignificantly smaller in terms of dependencies (allowing more usage in more formulae)
- we should consider having some
${FORMULA}-full/${FORMULA}-minimalformulae for maximal/minimal cases of formula and keep${FORMULA}for "the functionality that we need for dependencies in Homebrew itself". This would likely help make e.g.ffmpegsignificantly smaller in terms of dependencies (allowing more usage in more formulae)
Sounds like that would require ${FORMULA} to be keg-only, in order to coexist with ${FORMULA}-full or ${FORMULA}-minimal. Alternatively, addressing https://github.com/Homebrew/brew/issues/16398 might help resolve this in a user-friendly manner, where ${FORMULA} is pulled in as a dependency but users prefer ${FORMULA}-full for active use.
Sounds like that would require
${FORMULA}to be keg-only, in order to coexist with${FORMULA}-fullor${FORMULA}-minimal.
Yes, one or more of these would need to be keg-only.
users prefer
${FORMULA}-fullfor active use.
I'm not sure this will be the case for e.g. ffmpeg with a very deep dependency tree.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.