Let's see if we can get the elegance, simplicity, and speed of Homebrew for the installation and management GUI Mac applications like Google Chrome and Adium.
brew-cask provides a friendly homebrew-style CLI workflow for the
administration of Mac applications distributed as binaries.
It's implemented as a homebrew "external
command" called
cask.
First ensure you have Homebrew version '0.9' or higher:
$ brew --version
0.9.3
Tap this repository and install the brew-cask tool:
$ brew tap phinze/homebrew-cask
$ brew install brew-cask
Let's see if there's a Cask for Chrome:
$ brew cask search chrome
google-chrome
Cool, there it is. Let's install it.
$ brew cask install google-chrome
Downloading...
Success! google-chrome installed to /usr/local/Cellar/google-chrome/stable-channel
Now we have Google Chrome.app in our Cellar. Cool.
If you like, it's easy to get it linked somewhere more visible (see "Alfred Integration" below for an idea that makes this step unnecessary):
$ brew cask linkapps
/Users/phinze/Applications/Google Chrome.app -> /usr/local/Cellar/google-chrome/17.0.963.56/Google Chrome.app
And there we have it. Google Chrome installed with a few quick commands; no clicking, no dragging, no dropping.
open "~/Applications/Google Chrome.app"
Just run brew cask search with no arguments to get a list.
Since this repository is a Tap, you'll pull down the latest Casks with a simple
brew-update. When the brew-cask tool itself is updated, it will show in
brew outdated and you can upgrade it via the normal Homebrew workflow.
A Cask is like a Formula in Homebrew except it describes how to download
and install a binary application.
Casks currently have three fields:
- url: (required) points to binary distribution of the application
- version: (required) describes the version of the application available at the URL
- homepage: the same as Homebrew's - it doesn't do anything yet, but will be wired in
It's really just a start at this point, but it works, and I've got big plans!
brew-cask currently understands how to install dmg and zip files that
contain a .app file. I'd like to extend it to be able to handle pkg files
as well as the numerous other permutations of compression and distribution in
the wild (.app inside dmg inside zip; folder inside dmg; etc.).
I plan to use the Cask model to allow per-project customization of behavior,
like Homebrew does with Formula. This would allow weirdo applications like,
say, Eclipse ("you really want me to drag that whole folder to
Applications? ew.") to contain their complexity.
Each Cask will then encapsulate and automate the story of how a given application should be installed. If all goes well - I'm hoping to build up a community-maintained collection of Casks that becomes the standard way that hackers install Mac apps.
Yes, yes, yes! Please fork/pull request to update Casks, to add features, to clean up documentation--anything at all that you can do to help out is very welcome.
It's also pretty darn easy to create Casks, so please build more of them
for the software you use. And if brew-cask doesn't support the packaging
format of your software, please open an issue and we can get it working
together.
The whole idea is to build a community-maintained list of easily installable packages, so the community part is important! Every little bit counts.
You can add Casks to your existing (or new) taps: just create a directory named
Casks inside your tap, put your Casks there, and everything will just work.
You can set options on the command-line and/or using the HOMEBREW_CASK_OPTS
environment variable, e.g.:
# This probably should happen in your ~/.{ba|z}shrc
$ export HOMEBREW_CASK_OPTS="--appdir=/Applications"
# Installs to /Applications
$ brew cask install a-cask
# Trumps the ENV and installs to ~/Applications
$ brew cask install --appdir="~/Applications" a-caskI've been using Casks along with Alfred to great effect. Just add
/usr/local/Cellar as a Search Scope in Alfred's preferences, and then
applications become available in Alfred immediately after a brew cask install. Your fingertips will thank you.
With this setup, you don't actually need brew cask linkapps if you always
open your apps from Alfred. This means that everything stays nice and tidy.
Oh, and you can brew cask install alfred too! Not bad, eh?
The short answer to this would be: for the same reason that Homebrew does not
install applications directly into /usr/local.
We don't know up-front precisely what files are going to be in the
dmg/zip/tgz/etc, so it's really helpful to have a place to dump all of them
safely then iterate through and act on the files we care about. For a .app
file this may be symlinking it into ~/Applications or /Applications, for a
.pkg file this might be running the installer. For a screensaver it may be
symlinking it into the appropriate directory for it to show up in System
Preferences.
The reason I implemented this project on top of Homebrew was because I believe
that their methodology for managing applications has a lot of merit. I'd prefer
to try and work things so that we can keep ourselves Homebrewy both in
implementation and idioms. Trying to manage all of ~/Applications would move
the project more towards a standalone system, which would mean reimplementing a
lot of the Homebrew stuff we lean on now.