= New Concept: Cask::Artifact
An Artifact is a file in an extacted container for which homebrew-cask
should take some sort of action on install/uninstall.
== Current artifacts:
- App: link/unlink to ~/Applications
- Pkg: install/uninstall (with sudo)
- Prefpane: link/unlink to ~/Library/PreferencePanes
= New Feature: Preference Pane Handling
Specifying `prefpane 'MyApp.prefPane'` in a Cask causes it to be linked
on install to the correct location for it to show up in System
Preferences.
refs #69
= Removed Commands: linkapps/unlinkapps
These were old and mostly unused and don't really make much sense when
linking/unlinking happens automatically in the install process.
= Changed Behavior: stricter relative pathname requirement
With this refactor, we remove the fuzzy searching for a file in an
extracted container when that file was referenced from `link`
or `install`. There may be some casks that need to be updated due to
this change.
- re-added a lost nil guard on `Dmg` containers
- `FakeSystemCommand` was still returning an array of split lines
instead of a string, even though its real counterpart switched to
string when install/uninstall landed
- flushed out an alfred cli bug
- moved plist parsing down to SystemCommand layer
`Cask::Installer` was already much too complex, so I took this
opportunity to throw a `Cask::Container` abstraction around the
extraction part of the package install step.
It goes like this: a Cask's URL points to a Container of some sort. The
containers we currently support are: dmg, zip, tar, and (new) naked.
Naked refers to a raw file that just needs to be copied in place. This
currently just means a pkg file, but in the future it may expand.
A Container knows how to do two things: identify a path as being its
type (`Container.me?`) and extracting the contents of its container to
the proper destination for a Cask (`Container#extract`).
The first Cask we have that supports the naked pkg type is
`heroku-toolbelt`. (Thanks to @sheerun for the Cask definition.)
Other miscellania batched in with this refactor:
- switched to an explicit require strategy rather than globbing
- `Cask::Installer` is instantiated now to match its interface with
other similar collaorators
- simplified zip and tar identification to shorter strings rather than
exact matches of full `file -Izb` output
- `Cask::SystemCommand` gets explicit output redirection options
- many rogue backticks replaced to properly use `SystemCommand`
- fixed misnamed test file `link_checker_spec.rb`
- remove some extraneous `after` clauses in tests; leaning more on
`test/support/cleanup.rb` to uninstall for us
- pkg uninstall `:files` gets a `-rf` to support removing dirs
refs #839 and #1043
accepts a single argument, which is a relative path to a pkg
inside the extracted Cask; homebrew-cask will attempt to install this
pkg after the Cask is extracted via `installer`
because of the many different ways uninstallers work, this
has several features:
- `:script`: a script in the Cask which serves as an uninstaller (e.g.
Vagrant, VirtualBox), uses `:args`, and `:input` keys to interact
with said script
- `:pkgutil`: a regexp which captures all package_ids installed by this
cask; homebrew-cask will list all files installed under these ids and
remove them
- `:launchctl`: a list of bundle_ids for services that should be
removed by homebrew-cask
- `:files`: a fallback list of files to manually remove; helps when
uninstallers miss something
refs #661
this was preventing the `brew cask install --force cask` syntax from
working
the test was wrong too - corrected that so now we're covered from future
breakage
refs #329
this was exposed in #313 by @vitorgalvao in his attempt to update the
anvil cask; by adding a link to that cask, (which just so happens to be
the cask that we chose for our "already uninstalled message" test).
the fix is simply to move the "already uninstalled" check *before* we
start to unlink.
- the vagrant cask is our guinea pig
- works for me
- only basic testing at the moment
- i wanted to push something to get the gears turning on this
it turns out the concept is pretty simple. specify a list of pkgs to
install; borrow the patterns from linkables for that. then basically
just run "sudo installer"
refs #14
the create command opens up an editor with template to get started
remove --create override flag from `brew cask edit`
hopefully this will be more straightforward for contributors
refs #306
`md5`, `sha1`, `sha256` all take a hexdigest string, e.g:
sha1 'f645e9da45a621415a07a7492c45923b1a1fd4d4'
`no_checksum` takes no argument, and indicates there is no checksum
for this cask. This is *not recommended*, and should only be used for
casks that have no versioned downloads.
`brew cask install` will complain if there is no sum provided (unless
`no_checksum` has been invoked), or if the sums do not match. It will
provide the computed checksum so the cask can be easily amended.
Adapted from @passcod's work in 82cc199ae6bbb1e98950e71a0573ab48e6a641ee
homebrew does internal caching in ARGV that prevents us from doing the
`ARGV.clear; ARGV << 'newarg'` trick twice.
rather than try to further reach in to homebrew's innards, i figure it's
better to just pass multiple arguments down to homebrew code at once,
since it already supports that
refs #47
this delegates to homebrew's uninstall to get its work done. vanilla
`brew uninstall` actually works, but this gives us a more consistent
interface.
as discussed in #47
Most notably, Cask.all returns an array of strings,
not of Cask instances. This makes things easier, as
well as faster, as there's no need to run map(&:to_s)
everywhere anymore.
self.path is a utility method which returns the path
of the cask from its title. There's something subtle
going in there:
- If `cask_title` is fully qualified, e.g.
"phinze-cask/alfred", it's straightforward.
- If `cask_title` is only the name, e.g.
"firefox-aurora", the name is matched from
the full list (self.all) (which isn't sorted)
and the first result is returned.
Hence, self.path with only the name is not precise.
There might be the possibility to apply heuristics
to do a better match (prefer phinze-cask, or maybe
installed casks?) but that's for another issue :-)
self.nice_listing is another utility method used
in `search` and `list`. It returns a list where
unique casks don't have a prefix, and duplicates
do. The prefix is the tap name. The list is then
sorted. For an example or two, look at the first
comment on phinze/#12.
Instead of only listing `Taps/phinze-cask/Casks`, now list
every taps that has a `Casks` directory. Might conflict with
a few commands for the moment, works OK with `brew cask search`.
