Step 2: Snapshot the Cask file used at install-time, using
the previously-merged metadata directory support.
Using a simple filesystem-is-a-database approach, we set up a
`.metadata` directory for each installed Cask in which we can
record any information, starting with a copy of the Cask
definition which was used at install-time.
This should be useful for various cases such as:
- a fallback when the Cask was renamed/removed. We
currently cannot recover any uninstall info in that
scenario
- installation of multiple versions of the same software
There might be a smarter way to discover the source filename
for the Cask through introspection or some deep Ruby voodoo.
All I could come up with was to pass the filename in on the
constructor, which seems perfectly reasonable if voodoo is
not available. The existing code was taking the title as an
argument to the constructor, which is dispensable.
This PR contains no code to actually make use of the metadata,
but only takes care of the relevant book-keeping: creation,
destruction, as well as organization of metadata according to
software version number and timestamp.
Class names are now completely hidden from the user. This
commit works by adding a prefix to all Cask class names, which
is considered to be an ugly transitional hack on the way to
representing individual Casks as instances.
* "Canonical App Name" becomes "Simplified App Name"
* devscript `cask_namer` renamed to `generate_cask_token`
* doc file `CASK_NAMING_REFERENCE.md` renamed to `cask_token_reference.md`
* DSL uses `"#{token}"` for interpolation instead of `"#{title}"`
* documentation text
* backend code (variables, method, class names)
* error message text
* tests
* code comments
* Cask comments
* emphasize `tags :name`
* doc: use "vendor" consistently instead of "developer"
* doc: many man page argument descriptions were incorrect
* incidental clarifications
Many backend variables similar to `cask_name` or `cask` have
been standardized to `cask_token`, `token`, etc, resolving a long-
standing ambiguity in which variables named `cask` might contain
a Cask instance or a string token.
In many places the docs could be shortened from "Cask name" to
simply "token", which is desirable because we use the term "Cask"
in too many contexts.
* part of DSL 1.0 review
* `destination_path` was always a bit vague (it refers to
Cask-specific, version-specific location under
`/opt/homebrew-cask/Caskroom`)
* here renamed `staged_path` to match upcoming command verb
`brew cask stage`
* rename also intended to reduce confusion when we implement
copying as a configurable alternative to symlinking
* transitional `destination_path` methods to remain while
Casks are converted (this was documented as a part of the
DSL, and used by 39 Casks in main repo)
* unrelated variables containing "stage" recast for clarity
Change namespace for clarity, as we already have Cask::Installer,
and are about to add Cask::DSL::Installer.
Move to parent because these methods are not DSL-specific.
Forgotten in #4688, but should be considered part of Cask DSL 1.0.
A `depends_on` stanza is much less useful without the corresponding
`conflicts_with`.
References: #4896
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
To aid in Tap transition. Require Homebrew 0.9.5, rescue
`rename_tags_dir_if_necessary` (`respond_to?` won't work there
because `rename_tags_dir_if_necessary` is a private method.
References: #4192, @Jackiebo in #4096
At every command execution
- invoke `rename_taps_dir_if_necessary` to help with Homebrew's Tap migration.
(Homebrew's migration seems to sometimes fail to fire, see #4096)
- untap `phinze/cask`, and tap `caskroom/cask`, to help with our own move
to a GitHub organization
After a few months, this can be reverted.
closes#2996. Moves the logic for creating target directores
from init-time in cask.rb to install-time within the artifact
classes. Removes the need for special-case mkpath for each
new artifact type.
- add new file "cask/utils.rb" analogous to "utils.rb" in Homebrew
- define odebug and odumpcask, analogs of ohai and friends, but
which only give output when --debug is in effect
- move the debug setting from an instance variable in Cask::CLI
to a method Cask.debug, defined in "lib/cask/options.rb", which
was added in #2276. (Perhaps options.rb should be merged back
into Cask::CLI).
- sprinkle odebug statements liberally throughout the codebase
- update tests
For safety.
- This is a step toward reworking system_command.rb so that
invocations are done in list form on the back end, avoiding
surprises from quoting and shell metacharacters.
- There is one transitional hack here: the _quote method in
Cask::SystemCommand is modified to avoid double-quoting. The
_quote method itself will go away in a future revision when
only list-forms are used.
- Casks using system are not touched. It seems natural to
address that when creating the DSL for after_install/before_install.
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.
