App categories + descriptions

[andreis]

I think it would be useful to have categories for apps (i.e. editor, game, utility, window manager, terminal, etc.) and publish the lists of apps in each category on the wiki. Even better, a category string can be added to the app metadata, then the wiki could be modified automatically at each new commit (not sure this is possible), and additionally we'd gain introspection when running brew cask.

Expanding on this idea, an app could also have a short description string. When running brew cask info <app> we could do something like println app.categories app.description:

Example:

$ brew cask info dropbox
[utility] [cloud storage] Official OSX client for Dropbox
dropbox: latest
https://www.dropbox.com/
/opt/homebrew-cask/Caskroom/dropbox/latest (640 files, 51M)
https://github.com/phinze/homebrew-cask/commits/master/Casks/dropbox.rb
==> Contents
  Dropbox.app (link)

[vitorgalvao]

Both categories and descriptions have been discussed before. None of homebrew-cask’s goals is app discoverability (for various reasons, please refer to the linked issues for more details), so these have been rejected already.

[beNjiox]

Quick question - I thought it would be fun to code something as a side project on top of brew cask, which would add description and other "social" kind of feature often discussed here.

Would you be against that? (Actually I've already started something cool, but I prefer to stop right away if this is not something you would like to see)

Thanks,

[vitorgalvao]

This is open-source, after all, so you’re free to do it and I doubt any contributor would be against it (pinging @rolandwalker and @ndr-qef for opinions, as well).

However, as you know from this and similar issues, discoverability is not something we’re pursuing with this project. We’ve recently been discussing security a bit more, and it is true that by not concerning ourselves with such features, it is hard for hypothetical included malware to spread, since you have to know about an app before deciding to download it; your project would change that¹.

With this in mind, I’d personally like if your project made clear the (obvious to us) fact that you should always be careful about which sources to trust, and their fallibility. This does not at all excuse carelessness in our part, naturally, but mistakes do happen (I’m no exception), and increased risk deserves increased warnings.

---

¹ Imagine a cask that links to some malware disguised as an app, being included. It wouldn’t spread far since a user would need to know about the malware app already (even if thinking it was a legitimate app) and explicitly choose to download it. With such discoverability features, this is no longer the case, as a user can easily find and download such apps on a whim.

[rolandwalker]

Hi @beNjiox !

We support interoperability with other projects, and provide an interface for subcommands (see developer/examples. I am happy to assist with bridging our data for other projects.

Keep in touch, and let us know what you are working on. (But use IRC, or open a fresh issue — if Vitor hadn't pinged me I wouldn't have seen this.)