-
Notifications
You must be signed in to change notification settings - Fork 0
Acceptable Formulae
Some formulae should not go in Homebrew/homebrew. But there are additional Interesting Taps & Branches and anyone can start his/her own!
However, we do like dupes in the tap!
Stuff that comes with OS X or is a library that is provided by RubyGems, CPAN or PyPi should not be duped. There are good reasons for this:
- Duplicate libraries regularly break builds
- Subtle bugs emerge with duplicate libraries, and to a lesser extent, duplicate tools
- We want you to try harder to make your formula work with what OS X comes with
There are exceptions. Mainly for stuff that is very well designed to be installed in parallel to other versions of itself or for stuff that people really need:
Formula | Reason |
---|---|
Ruby | People need version 2.0 |
Python | People want version 2.7 and 3.x |
Bash | Version 4 is cool |
Emacs | Too popular to move to dupes |
Subversion | For some tasks Homebrew requires a newer version than OS X 10.5 provides |
Zsh | This was a mistake, but it’s a bit too late to remove it |
libcurl | Some formulae require a newer version than OS X 10.5 provides |
openssl | Some formulae require a newer version than OS X 10.5 provides |
libxml2 | The version that is bundled with OS X has some notable crash bugs |
cairo | Cairo is not provided by OS X 10.5, and some formulae require a newer version on 10.6 as well |
e.g. recently we removed the formula for npm. We worked with the maintainer of npm to do this. It was the best decision for npm and Homebrew.
Because that circumvents our hash-checks, makes finding/fixing bugs harder, often breaks patches and disables the caching. Almost always you can add a second formula into the main formula file to handle the separate download and then the installer script will not attempt to load that stuff on demand. Or there is a command line switch where you can point it to the downloaded archive in order to avoid loading.
Our policy is that formulae in the core repository (Homebrew/homebrew) must be built from source. Binary-only formulae should go to Homebrew/homebrew-binary.
Formulae in the core repository should have a stable version tagged by the upstream project. Tarballs are preferred to git checkouts, and tarballs should include the version in the filename whenever possible.
Software that does not provide a stable, tagged version, or had guidance to always install the most recent version, should be put in Homebrew/homebrew-headonly.
First check that there is not already a binding available via
gem
or pip
etc..
If not, then put bindings in the formula they bind to. This is more useful to people. Just install the stuff! Having to faff around with foo-ruby foo-perl etc. sucks.
The software in question must be
- maintained
- known
- stable
- used
- have a homepage
We will reject formulae that seem too obscure, partly because they won’t get maintained and partly because we have to draw the line somewhere.
We frown on authors submitting their own work unless it is very popular.
Don’t forget Homebrew is all git underneath! Maintain your own fork or tap if you have to!
Don’t make your formula build an .app
(native OS X Application), we
don’t want those things in Homebrew. Make it build a command line tool
or a library. However, we have a few exceptions to that, e.g. when the
App is just additional to CLI or if the GUI-application is non-native
for OS X and/or hard to get in binary elsewhere (example: font forge).
Check out the homebrew-cask
project if you’d like to brew native OS X Applications.
The “superenv” is code Homebrew uses to try to minimize finding
undeclared dependencies accidentally. Some formulae will only work under
the original “standard env” which is selected in a formula by adding
env :std
. The preference for new formulae is that they be made to
work under superenv (which is the default) whenever possible.
Even if all criteria are met we may not accept the formula. Documentation tends to lag behind current decision-making. Although some rejections may seem arbitrary or strange they are based from years of experience making Homebrew work acceptably for our users.