References: #4688.
For forward-compatibility; intentionally left undocumented.
The `license` stanza is not free-form. There is a limited
set of valid symbols, of which the argument must be a member.
(The set will later be documented, and probably needs amendments.)
Version numbers and variants of licenses are intentionally
ommitted. The use-case for `license` is filtering and listing
of Casks. We want to avoid becoming a detailed repository of
application descriptions: that information can be found at the
`homepage` URL.
For forward-compatibility, intentionally undocumented. Currently
works only as a synonym: `depends_on :formula` substitutes for
`depends_on_formula`, which is intended to be removed.
However, this PR also provides additional `depends_on` keys for
future expansion of functionality:
- `:cask`
- `:macos`
- `:arch`
- `:x11`
- `:java`
The symbol names were chosen to match those used in Homebrew Formulae.
References: #4688, #2001
`sha256 :no_check` has been supported syntax for a couple of months,
and now is being transitioned to the preferred syntax, replacing
the `no_checksum` stanza (which will still be supported, but
deprecated)
Fixes#2997. Interface is optional DSL stanza `container_type`.
This should only be used in rare instances. It is needed for the
case of a naked executable which should not be unpacked.
to `wiztoolsorg-restclient.rb`, per naming rules in `CONTRIBUTING.md`.
This requires making changes to the test suite, as the tests used this
cask. Imported special test Casks for the relevant test no longer has
a dependency on real Casks.
Adobe Air applications take the form of a .air file that the Adobe Air
runtime then installs and creates a .app -- typically in
/Applications. This patch provides a new container for those .air
files which the Adobe Air runtime installs to the Caskroom as well as
tests for Adobe Air app installations.
Presently, if homebrew-cask doesn't detect the Adobe Air runtime, it
will provide an informative error message and instructions to obtain
it via `brew cask install adobe-air`. This is obviously not ideal and
the installation process for the runtime should be automated in the
future.
Fixes#2601
- do a soft test to see if the service is loaded before attempting remove
- test/unload as both superuser and user as the service can be installed
differently according to the original packags
- add tests for uninstall :launchctl; there were none previously
Make caveats a first-class member of the Cask DSL. It no longer has to
be specified with "def caveats", but can be given as "caveats do ... end"
as with after_install blocks.
In addition, create a mini-DSL which can be used within caveats blocks,
providing standard messages when manual installers must be used,
reboot-required, etc.
Add alternate form: caveats can also accept a compile-time string for
simple cases.
This is 99% compatible with old Casks, as it still works by defining
a caveats method. However, all Casks containing caveats are cleaned
up and adapted according to the new DSL.
Full docs in CONTRIBUTING.md.
The indentation in CONTRIBUTING.md implies that :script accepts a hash.
But that is not the case. Instead :script accesses the entire hash defined
by uninstall. Unrelated install keys such as :quit leak through to
@command.run! when attempting to exec :script. Result: contrary to docs,
:script cannot be combined with other uninstall keys.
This PR makes uninstall :script accept a hash. When :args or :input are not
needed, :script can still accept a plain string, so many Casks require no
alteration.
In addition
- adds key :executable, required when using hash argument to :script
- keys to :script are validated and sanitized before being passed to
@command.run!
- adds :quit to with-installable.rb test to protect against regression
on leaky keys
- this allows us to support casks for things like "dmg in zip" "zip in
tar", etc, etc
- a nested container can be any format that homebrew-cask supports
- the existing container support is now referred to as a Cask's
"primary container"
- use the `nested_container` artifact type to indicate the relative
path to a nested container that you wanted extracted
- multiple layers of nesting should work with multiple nested_container
directives (though this is untested as yet)
- add SpeedDownload as the first cask to use this feature; refs #602
= 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.
`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
- 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
