Change casks to use a data format, not code

[hpoom]

At the moment casks are code files; they are .rb files that contain a class definition. It would be better to use JSON, or YAML, ideally JSON as these are just data. They do not contain code so having them as .rb seams to restrict future flexibility.

In the future, maybe you should support JSON from remote hosts, so the files don't have to exist in in your Casks folder. Instead you could link to www.mydomain.com/myBundle.json

In short: use a data file to store data not a code file format.

[vitorgalvao]

I can’t say for sure (@phinze or @passcod should be able to confirm), but that could possibly create some problems regarding integration with homebrew (the non-cask one). There are also some instances where the fact they’re runnable code has come in handy (albeit only in proof-of-concept ways, there has been work maintaining casks execution-free). I’m not opposed to having casks in a data format, but I’m not sure the current “marriage” to the other project would allow it.

Regarding linking to an external file, that could be done with the casks as they are (Homebrew also does that), and it is an old issue.

[passcod]

Quick note before I leave a more complete answer:

having them as .rb seams to restrict future flexibility

No. Having them as data would restrict flexibility. Being able to run code enables, for example, parsing options and making choices as to what to install when. The features that would take advantage of such aren't there yet, but they are prototyped and being discussed on.

There is a variety of package managers out there, but I have yet to see any general purpose one that doesn't allow execution of scripts.

And funally, we are indeed tied to Homebrew, which means even though both our specific formats are different, the encapsulation format remains the same. You are more than welcome to try and create a package manager that uses Json or Yaml, and I would think it possible to make some kind of plugin or compatibility layer so it works through Homebrew or Casks. But I do not think it 'll ever become part of the main project itself.

As I said, just a quick note ;-)

[passcod]

I am aware that seemingly conflicting statements may appear here and there, e.g. most recently #398 "we try to keep casks [...] without any runnable code." There's actually more nuances than that, but it's all part of the discussions (and you are welcome to take part. See: #6, #14, #69, #125, #164, #204, #260, #277, #304, #343 to number just the few(!) current proposed syntax alterations). Keeping it as code allows, for the moment, a flexible take on the future.

Besides, ruby code is nice. What would you prefer?

---
name: FooBar
url: 'http://www.example.com/foobar-1.2.3-mac.dmg'
homepage: 'http://foob.ar'
link: 'Foo.app'
version: '1.2.3'
sha1: '8b6d62d599caef72852bb42c886c0b230e11b42b'

class FooBar < Cask
  url 'http://www.example.com/foobar-1.2.3-mac.dmg'
  homepage 'http://foob.ar'
  link 'Foo.app'
  version '1.2.3'
  sha1 '8b6d62d599caef72852bb42c886c0b230e11b42b'
end

...huh. Not as clear a point as I'd hoped to make. Y'know, the lad may have a point. Not if we take JSON, though:

{
  "name": "FooBar",
  "url": "http://www.example.com/foobar-1.2.3-mac.dmg",
  "homepage": "http://foob.ar",
  "link": "Foo.app",
  "version": "1.2.3",
  "sha1": "8b6d62d599caef72852bb42c886c0b230e11b42b"
}

...actually, let's make up our own grammar!

# foo-bar.cask

url       http://www.example.com/foobar-1.2.3-mac.dmg
homepage  http://foob.ar
link      Foo.app
version   1.2.3
sha1      8b6d62d599caef72852bb42c886c0b230e11b42b

Nah, we probably won't change it. Why? We can provide a variety of reasons, but in the end, it's what @phinze started with, and we stuck with it throughout. It's not a bad choice per se. It's not the best one. But it's part of what makes homebrew homebrew and what makes cask cask. I can actually think of a lot more advantages to JSON or YAML or our own grammar... than disadvantages, but that's not counting the cost of change, and the loss of identity. Let us have this lithe weakness, and proudly go into darkness.

[muescha]

How about to add to the Cask class a to_json or a to_yaml ?

[passcod]

I don't see what that would do.

[sdegutis]

👍

[tjnycum]

I don't really know Ruby and don't have enough familiarity with homebrew and cask under-the-hood to judge the strengths and weaknesses of various implementations, so I don't really have an opinion on this data vs. code issue at this point. However....

But it's part of what makes homebrew homebrew and what makes cask cask. I can actually think of a lot more advantages to JSON or YAML or our own grammar... than disadvantages, but that's not counting [...] the loss of identity.

I have to say that's one of the stranger—not to mention, more circular—arguments I've read regarding a proposed software change. The mission of software for general use is to fill a functional need (i.e. have a particular effect), not to have some "identity" or continue as some kind of memorial to whatever the initial approach happened to be. The vast majority of homebrew and cask users (except those who were just following instructions to get x working) installed and use them because they wanted and want powerful yet user-friendly command-line package management on their Mac. They don't care whether it uses Ruby internally or whether the "formulas" are "data" or "code". If developers want to think of their work as helping the user-base, the behavior should be the software's identity in their minds. The implementation is just a means to that end.

[passcod]

It's a complex issue, and it's been two years… Identity and image do have some importance, though. The game is not only "developers [wanting] to think of their work as helping the user-base", it's developers wanting to continue working on the project, especially in open-source, voluntary, in-their-spare-time projects. Take out the identity of the project, some core part of it, and you might find that developer interest wanes, leaving a piece of software that everybody uses but nobody wants to make.

Again, it's been two years, and I cannot be sure that's what I meant, but Cask at that time was still quite the Homebrew "plugin". The identity of Cask was, and still may be (can't say for sure, I'm not involved in Cask development nor usage anymore), intricately linked to Homebrew's, especially on this issue. Cask was riding on Homebrew's user-base, at some point, so would changing the format have made it more difficult for those users to use? Who knows.

As the discussion above makes apparent, there were some weak arguments for, some weak arguments against, and then there was a bit of overhead to such a change (have to switch the repository to it, have to switch user expectations, have to teach existing users...). The two biggest considerations, for me, I think, were "what would phinze want?" and "what do I think Cask is?".

I would have been swayed, and I think the current maintainers would still be swayed, by strong, well-reasoned arguments. I weighed both sides, considered the various options, and that didn't decide me. I think I was in a facetious mood, hence the tone of my posts. I don't know. Maybe it was a good idea. Or maybe not. Certainly nobody did argue against my rejection of the issue, so it can't have been that contentious a decision.

As a final note, on the necessity for vision and identity:

Every single person, every single organization on the planet knows what they do, 100 percent. Some know how they do it [...]. But very, very few people or organizations know why they do what they do. And by "why" I don't mean "to make a profit." That's a result. It's always a result. By "why," I mean: What's your purpose? What's your cause? What's your belief? Why does your organization exist? Why do you get out of bed in the morning? And why should anyone care?

[x]

And by "why", I don't mean "to fill a functional need"…