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.
This takes the form of a horrible hack: DSL version numbers may
end with "test", *eg* ":v1test". Such Casks are mapped to class
`TestCask` instead of class `Cask`.
The intention is that all of this logic will be removed when
Casks are migrated away from separate classes.
Tests driven by RSpec are still todo.
Currently, Casks names are constrained by the need to form
valid Ruby class names. This change enables a new syntax,
in which the first line of a Cask will read like
```ruby
cask :v1 => 'my-app' do
```
where :v1 refers to the version of the DSL spec.
