DSL: improving support for binary artifacts

[tapeinosyne]

As part of our work toward an acceptable, mostly stable DSL 1.0, we should address several issues around our support for “naked” binary casks. As this is a matter of general interest for the project, I invite both @caskroom/maintainers and general users to voice their opinions.

We are currently limited to our binary stanza (doc), which links a single file into /usr/local/bin. This behavior is insufficient for much precompiled software.

@rolandwalker mentioned that extensions to binary should be backward-compatible; we can also introduce new forms if need be.

The most obvious extension, cosmetic in purpose, would be to allow binary to take an array of artifacts:

binary 'artifact'
binary ['artifact1' .. 'artifactn']

This would improve packages which include a copious number of /bin artifacts, as exemplified by terraform.

More importantly, binary distributions often include material which must be linked elsewhere. Our kludge of choice is artifact, as used in cargo.

Ideally, the most common materials and their destinations should be supported with simple keywords. It might also be desirable to link everthing in a folder recursively, instead of specifying every individual file. For example:

binary :bin => … # artifact, array, or folder/wildcard
       :lib => 'caskname/lib/*'
       :share => …
       …

[rolandwalker]

The array form should not be common enough to be needed, with support for a glob argument.

Globs should be available everywhere in the DSL that we refer to a file, but glob expansion really must be explicit. I started working on that in #5043, but never merged because the interface was clunky.

If we could separate ourselves from Homebrew per #5080, and run only Ruby 2.x, I wanted to look into whether we could fiddle with String classes via refinements and permit globs elegantly via 'caskname/lib/*'.expand. Otherwise something like expand('caskname/lib/*') is needed.

Linking everything in a hierarchy recursively ought to be a separate interface. That use case does exist, per #7442.

This overall issue is related to the need to have a generic way to install Library artifacts (#6387). An alternative interface might identify the common locations by methods, eg

  usr.bin 'executable'
  usr.lib 'library.a'
  usr.share 'directory'

Perhaps all along we should have been writing

  lib.font 'fontname'

[tapeinosyne]

The array form should not be common enough to be needed, with support for a glob argument.

Agreed.

Linking everything in a hierarchy recursively ought to be a separate interface. […]

This overall issue is related to the need to have a generic way to install Library artifacts (#6387). An alternative interface might identify the common locations by methods […]

A set of usr.subfolder stanzas is an intuitive option for improved support of naked binaries. However, I feel that offering both binary and usr.bin would be confusing.

I should also emphasize that all our stanzas use either the name value or the name :key => value syntax, and internal consistency is desirable.

Perhaps all along we should have been writing lib.font 'fontname'

That may be the case. (I think Homebrew employs a similar pattern.) However, I am not sure that the DSL generally benefits from explicit artifact location, even if the underlying methods are identical.

[ardecvz]

Hello,

Have you reached a consensus regarding the generic way to install Library artifacts?

Personally, I'm interested in adding to the formulae some SIMBL plugins which should be placed in ~/Library/Application Support/SIMBL/Plugins to work (symlinks are OK, too). At first glance, these plugins could greatly benefit from cask as they are usually distributed without any installer or centralized way to control their installation.

As far as I know, there are around 10-20 SIMBL plugins in the wild so this amount could justify a new simbl stanza implementation (comparing with <10 colorpickers or =1 screensaver and =1 input_method). But I'm little confused with the fact that SIMBL is proprietary and it's not a built-in function of OS X (through it's open-sourced). Also, it seems that a further addition of new install stanzas are leading to an unnecessary mess...

Is it OK to add simbl stanza? Or is it more appropriate to use standard artifact with depends_on :easysimbl?

Or is it better to move to a more generic way to install Library artifacts? If so, is there any further need to have separate stanzas to install a single screensaver, input_method and so on (and please keep in mind that in the future we would need one more stanza to install solely #6387)?

Thank you!

[rolandwalker]

Hi!

Unfortunately, we haven't made any progress on the interface for a generic Library interface.

However, as there are several SIMBL plugins, and as they follow a standard, we should support them with a specific stanza.

It would be best to file a separate issue for that.

[vitorgalvao]

Closing for lack of interest/implementation. This isn’t really a problem now, and can be revisited later.