# "To install, drag this icon..." no more!
[](https://travis-ci.org/phinze/homebrew-cask)
[](https://codeclimate.com/github/phinze/homebrew-cask)
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](https://github.com/mxcl/homebrew/wiki/External-Commands)" called
`cask`.
# Let's try it!
## Get brew-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
## Now let's install our first 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 /opt/homebrew-cask/Caskroom/google-chrome/stable-channel
Now we have `Google Chrome.app` in our Caskroom. Cool.
If you like, it's easy to get it linked somewhere more visible (see ["Alfred
Integration"](#alfred-integration) below for an idea that makes this step
unnecessary):
$ brew cask linkapps
/Users/phinze/Applications/Google Chrome.app -> /opt/homebrew-cask/Caskroom/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"
# What Casks are available?
Just run `brew cask search` with no arguments to get a list.
# How do I update brew-cask?
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.
# What is a Cask?
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
# What's the status of this project? Where's it headed?
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.
# Can I contribute?
__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 (see wiki)][c1], 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][c2]
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.
[c1]: https://github.com/phinze/homebrew-cask/wiki/How-to-Contribute
[c2]: https://github.com/phinze/homebrew-cask/issues
# Taps
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.
# Options
You can set options on the command-line and/or using the `HOMEBREW_CASK_OPTS` environment variable, e.g. (again, using google-chrome):
```bash
# This probably should happen in your ~/.{ba|z}shrc
$ export HOMEBREW_CASK_OPTS="--appdir=/Applications"
# Installs app links to /Applications
$ brew cask install google-chrome
# Trumps the ENV and installs app links to ~/Applications
$ brew cask install --appdir="~/Applications" google-chrome
```
# Alfred Integration
I've been using Casks along with Alfred to great effect. Just add
`/opt/homebrew-cask/Caskroom` as a Search Scope in Alfred's preferences (you
may need to press Cmd-Shift-G in the file chooser), 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?
# Why use the Caskroom? Why not just manage apps directly in `Applications`?
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.