DSL: add tags stanza

[rolandwalker]

only limited/defined keys are permitted

• :vendor
• :font_pitch
• :font_serif
• :font_weight
• :font_slant

forward-compatibility: no associated functionality is
provided. Intentionally left undocumented.

References: #4688, #2812

[tapeinosyne]

Would you consider :source to be a suitable candidate, despite coupling with the license stanza?

[rolandwalker]

I'm amenable to :source, especially if it is a direct repo URL, so that brew cask checkout iterm2 could be made to work.

However, other maintainers have expressed reservations against expanding tags too widely. I believe that all of us (myself included) are against subjective tags such as :description, or :category.

Perhaps, since I would attach functionality to :source, then I'm thinking wrong, and tags is the wrong place for it — perhaps it would better be added as its own (optional) stanza.

What's your use-case for :source?

[rolandwalker]

Just so we have something more to talk about and compare, I added :font_pitch, :font_serif, :font_weight, :font_slant keys to the PR. These are exemplary tags that would be used for filtering, and it happens that we can seed these values for most of the font repo using structured data from Google Font Directory.

Incidentally, I'd be keen to tag fonts according to Unicode coverage and/or language coverage, but I couldn't decide on the best interface.

[vitorgalvao]

Does Google Font Directory define them by such terms? :font_pitch would likely be clearer as :font_width.

I’ll also voice that I’m very much against tags in general, for similar reasons as to why I’ve always been against categories. “Not expanding them too widely” is, as I see it, a losing proposition. Tags are about nitpicking. Some will have too many information, others too few, causing inequality. Some will be too broad, and others too specific.

Let’s take typefaces as an example, since it’ll be particularly relevant there. What values does “serif” take? “Sans-serif” and “serif”? Well, we should probably also add “slab serif”. Well, since we’ve added slab, why not “old style”, “transitional”, and “modern”? Will we let Google Font Directory (GFD) be the definitive source for this? What about the fonts GFD doesn’t have? And are the classifications on GFD checked with professionals, or are they submitted by the creator, rendering them essentially useless? Some might have both “serif” and “slab serif”, which is correct, while others will only have one of those, causing confusion and frustration when searching.

Tags in general are a non-crucial feature, and they’re entering “categorisation territory”. I see them as nothing short of a distraction. Having pre-defined keys won’t make a difference as long as we can have freeform values. Having pre-defined values is not a solution, though, for the same reasons I point out in the above linked comment.

Homebrew-cask already supports so much, it’s on the verge of bloat. This feature in particular, when (not if) some casks inevitably end up with more metadata than others, will not only provide for a worse user experience, it’ll show (and cause) inequality between casks (and hence apps). Right now, we treat every cask the same; tags will inevitably change that, and I propose we shouldn’t allow it.

Sure, I’m pushing the boundaries of an unpleasnt scenario, but there is (was?) an explicit notion that homebrew-cask was supposed to follow the “one thing well” unix philosophy. Eventually there has to be a line that we decide we won’t cross, and it worries that there doesn’t seem to be a clear one.

[rolandwalker]

I'm glad that adding some specifics brought out discussion.

To be clear (about bloat) the current series of PRs on the DSL is intended to add forward-compatibility for the reasons laid out in #4688. No functionality is attached to tags, and this PR doesn't represent a commitment to do so. Any implementation is in the hazy future, and having familiarity with the code, a needed refactor of brew cask search is also standing in the way.

@vitorgalvao, you are right that tags is an ancillary feature. While my position on it is not as strongly held as yours, I lean towards inclusion for two pragmatic reasons: First: feature requests from Cask authors and maintainers, and second: scaling.

There are over 2,500 Casks now. There will be 10,000 soon enough. Improving searching/filtering/listing (whether or not it takes the form of tags) is skating to where the puck will be. (#2705, #2706, #2471, #2461, #2496, #1416).

You are also considering whether maintenance will scale, which is smart. We are already having trouble keeping up with certain Cask submissions (Java! #4524). The team must grow, regardless.

[tapeinosyne]

I would not worry too much about principles: the Unix philosophy has a certain malleability when applied outside of strict POSIX. The “one thing well” of Cask is the efficient installation of OS X software, which is a fairly wide concern.

My primary criterium for evaluating new “inert” stanzas (i.e. stanzas which carry information and do little else) is whether their value can be decided without discussion, thus minimizing maintenance cost. While even such stanzas contribute to bloat, I think that prioritizing minimalism over utility might be inconvenient in the long term.

In this case, I see utility in things like license and vendor (which can be used in searching and listing) and source (not only for brew cask checkout but also for its sheer importance in OSS).

I am more skeptical of font classification. As @vitorgalvao mentioned, traits like serif are problematic; slant might also be weaker than immediately apparent. I would be more amenable to pitch, which is unambiguous, and weight, which should be extractable from the font files. Even so, it might not be immediately clear what we mean with slant and weight: do they represent such properties as encoded in the font files, or do they describe the typeface's design?

A point to consider is that it might be hard to justify partial inclusion of font tags to the user. “Because it is marginally less fuzzy” is not a very good answer to “Why can I search by weight, but not serif?”.

[vitorgalvao]

My primary criterium for evaluating new “inert” stanzas (i.e. stanzas which carry information and do little else) is whether their value can be decided without discussion, thus minimizing maintenance cost (…)

I agree with those conditions. Although I still worry about making such non-crucial stanzas mandatory. And we do have to make them mandatory, or they’ll be either (close to) useless or cause segregation. The former makes for a worse experience for users (what should be there, isn’t, so you’re not finding something and can’t understand why); the latter positions homebrew-cask as an unfair playing field for developers (since more popular apps will invariably receive more care than others).

Regarding fonts, some of them don’t even use names for specifying characteristics, but numbers. And this is not that uncommon, since it was started by a famous type designer, that made some of the best/most used/most recognisable typefaces. I specially like the quote that he “designed his unique classification system to eliminate naming and specifying confusion”, and “[d]ue to some typeface manufacturers’ failure to understand and implement the system correctly, however, things have actually become more confusing” (you don’t say). Furthermore, “[t]o further complicate matters, the numbering system is not consistently applied to the Univers font family”; so we’re even admitting that the best typefaces can’t get it right.

[tapeinosyne]

Regarding fonts, some of them don’t even use names for specifying characteristics, but numbers. […]

The standardlust of industry people is certainly no concern of ours, but is there no formal weight encoding in OTF/TTF? There is in WOFF.

[vitorgalvao]

I’ve encountered fonts with names like TypefaceNameRegular.ttf and TypefaceNameBold.ttf, that when installed were indeed what was described in the name (“regular” and “bold”), but when used in design software were both shown as “regular”. Trusting the files for the classification will lead to unpredictable (and sometimes incorrect) results. Either way, it will not be consistent with what the user expects, and that type of predictability is paramount.

[rolandwalker]

Ah yes, Univers, or as I call it, The Hipster Helvetica. Hard to believe Wikipedia overlooks its largest deployment: the Paris Metro system.

So, we all agree on tags being unambiguous. I'm pretty certain that certain elements of font meta-information can be had unambiguously, for example, the covered languages (or "script"). Also, if some errors exist upstream, that's not a reason to not at least try.

Nevertheless, I have no concrete plans to work on an implementation, and am OK with dropping out the font tags – I amended the PR mainly to get some specifics for a discussion.

I am still followed by the nagging suspicion that if I want to use :source for functionality (not just listing), then it is not "static", and doesn't belong in tags at all.

[rolandwalker]

I'm merging this, limited to :vendor tag only. Still undocumented forward-compatibility mode.

When it comes time to document this, we can mark it experimental due to @vitorgalvao's concerns, and see how well it works in practice.