using depends_on for intra-Cask dependencies and metapackages

[rolandwalker]

Adding depends_on would not seem to be worth the effort for the small number of Casks with hard dependencies. (example: sshfs.rb depends on osxfuse.rb)

However, using a dependency framework for metapackages might be generally useful. I describe one such case in #1999.

Edit: Ruby thoughtfully provides TSort for the hard part.

Edit: depends_on :cask will be stubbed in the DSL in #4896.

Edit (by @ndr-qef): depends_on :cask has been implemented in #8491.

[tapeinosyne]

Verbatim from #8492:

Hard Cask dependencies can be used to create “metacasks” (#2001), which would be artifact-less Casks solely bundling other Casks. Such metacasks would serve the purpose of both automation (#6537, #5427, #6537) and unification of fragmented upstream packages (#1999).

(From here on, I will refer to the “metacask” as “Cask bundle”, after the deprecated brew bundle command.)

A terse approach would be to deem a Cask valid if it includes:

• any number of depends_on, and
• no artifact-related stanzas (installer, container, checksum, url, gpg…).

Alternatively, we could explicitly mark Cask bundles with a boolean stanza akin to stage_only, e.g. bundle:

cask :v1 => 'metacask' do
  bundle true

  # optionally
  version 'x.y'
  homepage '…'

  # payload
  depends_on :cask => '…'
  depends_on :cask => ['…', .. , '…']
  …
end

Beyond the DSL, we should define the behavior of Cask bundles in normal operations. Namely:

• Staging
  It may appear unnecessary to stage a Cask bereft of artifacts, but doing so will likely prove useful for the brew cask upgrade of Cask bundles, as described in Cask groups #4973 (comment).
• Uninstallation
  Similarly, assuming upgrades, the most desirable uninstall behavior for a Cask bundle would likely be to “unsubscribe” from additions, leaving previously installed dependencies intact.

[nicolas-brousse]

Two others alternatives that could be nice also :

cask :v1 => 'my-metacask', :type => :bundle do
  …
end

Or

metacask :v1 => 'my-metacask' do # Or bundle :v1 => 'my-metacask' do
  …
end

Else, for the Staging and Uninstallation I'm agree. But about the Uninstallation it could be complicated to define what is installed before. If a Cask depends_on two metacask how could make the difference?

[vitorgalvao]

Closing for lack of interest.