Formulae (info, search, etc) missing essential meta "description"

[mralexgray]

Apparently, according to Casks short description_ (issue #5192), this has been "refused" before - but let me present a super simple, side-by-side use-case in defense of why this feature is so essential (and missed).. ..

❯ brew desc -s github

gh: GitHub command-line client
ghi: Work on GitHub issues on the command-line
...
gost: Simple command-line utility for easily creating Gists for Github.
hub: Add GitHub support to git on the command-line
hubflow: GitFlow for GitHub

vs...

❯ cask search github

==> Partial matches
github-desktop githubpulse

Clearly, brews' output is more useful, usable, and user-focused. The feature disparity between the two is also confusing/unexpected/unfortunate.

OK, cask isn't about "discoverability". Fine. But even when explicitly asking for elaboration upon a specific formula, we are again left with less than ideal metadata (even if only compared to brew's managing-to-stay-minimal "description").

brew info gh

...
GitHub command-line client
...

❯ cask info githubpulse

...

_Please_ consider this feature - without prejudice. It would improve immensely - many people's ability to search, audit, utilize and enjoy the vast, yet very opaque benefits of this ecosystem.

[adidalal]

Brew's desc grew out of https://github.com/telemachus/homebrew-desc

Unfortunately, there simply isn't such a project for brew cask to start things out.

The original comment had some reasons why we have decided to not add descriptions.

Any thoughts on the above? If you have new ideas, we welcome a discussion; but as stated "I'm happy to entertain counterarguments here, but I'm just not seeing the work/benefit ratio working out for this."

Thanks.

[vitorgalvao]

The suggestion is welcome, but we don’t intend to become a discoverability service. This has been discussed and refused multiple times, as it is not part of the goals of homebrew-cask. Amongst other things, the logistics are unsustainable.

That’s my canned response for similar requests. I usually tailor it for the request in question, but that gets old, so please read all those links (and every link those link to) before continuing to reply. There’s simply too much context it’s a bore to keep repeating.

The feature disparity between the two is also confusing/unexpected/unfortunate.

Different projects, different needs and goals, and we both realise that. We’re trying to be closer, but for now, that’s what it is. Homebrew has the advantage of being extremely selective with what software it takes (must be open sourced and tagged with versions, for example) while we’re more of a free-for-all. We take almost anything because we can and it makes sense for our project. We serve different types of apps in different ways, hence we require different approaches. This makes it impractical for us to accommodate such a feature at this time. “Amongst other things, the logistics are unsustainable”.

We don’t have formulae, we have casks. It’s a different name because they represent a different thing, are structured in a different way, and perform differently.

But even when explicitly asking for elaboration upon a specific formula, we are again left with less than ideal metadata

brew cask home. All the information you want, always up to date.

We also have our own way of mitigating this issue, in the form of name, which just recently got a more prominent role, superseding the now (almost) defunct tags :vendor stanza. We’re not a discoverability service but we do understand the importance of searchability, which is why we include in name the software’s vendor and try to be as verbose as possible: so you can easily find what you’re looking for when you know what you’re looking for. When you’re just browsing descriptions to find something, you’re after discoverability. When you’re searching for vendors and app names, you’re going for searchability, making sure the cask you’re looking at corresponds to the app you want.

name makes more sense and is more sustainable in our context than desc.

_Please_ consider this feature

Do you think we haven’t considered it and refused it just because? We have considered it. Multiple times. And we have refused it with extremely detailed reasoning.

without prejudice

There’s no prejudice, here. If the feature didn’t fit us before and none of the things that were hurdles before have changed, then the answer hasn’t changed as well.

It would improve immensely - many people's ability to search, audit, utilize and enjoy the vast, yet very opaque benefits of this ecosystem.

It would also make our work that much harder, and most (against many) of our users understand that and do just fine. Again, “amongst other things, the logistics are unsustainable”. Many people like to come and say “make this happen”, but someone has to make that happen and keep supporting the system long after you’re gone. Stick around and see just the barrage of new casks we get, the amount of work it already takes just to make them correct, and then multiply that exponentially for descriptions¹. Many (perhaps most) new submissions don’t get license right, let alone a description.

I’ll leave this open for now, in case other maintainers want to comment or you have a reply for the above. I ask once more that you read all the provided links before commenting, though, and that you do not waste time to reply directly to my points² but to present clear, well thought-out solutions to the barriers we face, as well as implementations, your role in making them a reality³, how it can be made sustainable without putting all the burden of management on the team, how exactly descriptions should be structured, and anything else you deem relevant that pertains solely to the issue at hand.

Read our documentations, such as the token reference, and acceptable casks in another repo, and you’ll get an idea of the kind of detail and work we put into and expect from these considerations.

Lastly, I want to be clear very few things are set in stone for this project, but to many we know we can be certain in saying “not right now”. This is one of them, because at this point in time we cannot solve those issues. Perhaps when we join with homebrew we can start to think about this again, but not right now.

---

¹ Yes, exponentially, because when something is freeform but still requires rules, it requires that much work to get right.

² Because it’s getting old and I’ve likely already answered them over and over, and that’s not how I want to spend the holidays, or any day, even

³ As I said, we’ll not just have this “dumped” on the team to work on. I don’t necessarily mean coding, though. There’re many ways to help that don’t include coding, like availability to consistently and reliably discuss how things should be done, with pros and cons.

[vitorgalvao]

Closing, since there have been no new developments, and it’s unlikely they’ll happen. We should probably draft something about this to put on the documentation, and link users to. I intend to do it, and use the previous reply as a base for it.

I’ll add a final comment, though, and trust that I tell you this without judgement. You final paragraph shows a deep lack of understanding for how homebrew-cask works. One that I’ve encountered before occasionally, invariably in users who I’d never engaged with before. I’ve addressed all the points from that paragraph, though. All but one:

The system isn’t opaque. It is very transparent, and we work for it to be so. Do brew cask cat <cask-name> and you’ll see the whole contents of a cask. Everything related to a cask is contained in a small, easily auditable, easily readable file. in fact, we’re so committed to transparency we actively encourage users to audit casks. We even have special rules for casks with information a user otherwise could not easily verify (see “walled builds”). Look at our documentation. It is comprehensive and constantly revised; we take it seriously. There we not only explain how things work, but “why”, and are always available through this issue tracker.

Adding a one-line description doesn’t make the system more transparent.

I believe those misconceptions stem from the fact you don’t actually interact with the ecosystem (you may use the app, but you’re not involved with discussion or contributions). There’s not much we can do to fix that, except invite you to participate more (and you are very much invited and welcome).

I’ll also say again (and this is very important) that I present this conclusion without judgment. After all, I cannot even be sure you don’t usually participate. All I know is I haven’t interacted with your account before, and I’m here multiple hours a day, every day, since pretty early in the project. Nothing guarantees me you’re not actually someone I interact with daily with a dummy account, but like I said, I’m extrapolating the situation here to what I’ve seen before with similar users/accounts. In the end, you’re not obliged to interact with us; you’re perfectly free to only use the app and never delve into the innards of how the system works. However, I did feel it was appropriate to point out what I perceived as a misconception to how we actually work.