|
|
|
|
# "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 /usr/local/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 -> /usr/local/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.:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
# 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-cask
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
# Alfred Integration
|
|
|
|
|
|
|
|
|
|
I've been using Casks along with Alfred to great effect. Just add
|
|
|
|
|
`/usr/local/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.
|
