doc: Canonical name == App bundle name

[rolandwalker]

There's only one substantive change in this patch, which is
that the Canonical App name is defined exactly by the name
of the App bundle on disk. The suggestion that the author's
website be consulted for orthography is removed.

All but 18 Casks follow this rule already (if we leave aside
version numbers), so that's 98.3% compliance. I see this change
as documenting the de facto situation more clearly. The App name
on disk is in any case superior to consulting the website, as it is
less subject to misreading or artistic interpretation.

If this PR is accepted, I will

• rename the remaining variant Casks to follow this rule
• propose a PR to standardize version-numbers-in-names
• propose a PR for name name collisions.

Once the naming rules are fully specified, I'll PR a script which
a Cask author can use to generate the Cask Name and Cask Class
from a given App name, using the same logic as the backend.

[vitorgalvao]

Every time I write something against or for this approach, I think of new arguments that actually change my opinion, so please bear with me, I’ll try to be brief.

I started thinking this would not be a good idea, somewhat feeling there could be some cases where it’d break down — cases where you don’t have an app — when you install something and don’t see its effects on disk (plugins and drivers, for example). Then I realised we could name it the same as the file inside the downloaded package, naturally, and although that could lead to some of them having “installer” in the name, it should be sporadic enough to not matter.

Those are all pretty minor, considering the advantages of your suggestion, though. It does make it more convenient and less prone to errors when creating a cask, except in cases like parallels, where the user would have to mandatorily install it, to see the name of the resulting app (since the installer is named Install.mpkg). When installing a cask, I’m not at all convinced it’d be better. When I find a new app I want to try, just by looking at the website I’m on I can pretty much deduce what I should type after brew cask install. With the proposed approach, however, I’d have to first brew cask search something to find the correct name, since I’ll have no clue of what it’s actually called.

Like I said, I’m not fully committed to calling one approach superior, but right now I’m more inclined to the current one, and wanted to get those arguments out.

[rolandwalker]

These are good points, though I think we are somewhat talking about different things:

• I don't want to make any major change, just codify existing practice for the simplest case of an App link.
• the Cask changes I'm looking at in this phase are purely to do with hyphen placement, cases like "cdto.app" which is written as "CD to" on the web page.
• hyphen placement is now irrelevant to search after Improve cash search #2471 and followups
• there will always be corner cases we can't handle with rules. I don't propose to enforce caskname rules at audit time -- not at all -- just to make a straightforward creator script, especially for the first-time Cask author.
• I want to stop dupes such as dupe of Cask cloudpull.rb (the correct name) #2571 and remove dupe Cask sim-pholders.rb, update fields #2633 before they happen, patrolling for them is wasted time.

[vitorgalvao]

I don't want to make any major change, just codify existing practice for the simplest case of an App link.

Yes, that’s what I understood (and based my answer on).

the Cask changes I'm looking at in this phase are purely to do with hyphen placement, cases like "cdto.app" which is written as "CD to" on the web page.

And my point is exactly that how it is written on the homepage is more useful to someone that just found the app. Are we talking about the same app that is in homebrew-cask, though? Because that one is written as “cdto”, on its homepage.

hyphen placement is now irrelevant to search after #2471 and followups

I missed that. But is it irrelevant to installation? Because that was my point, being able to deduce the name of and install an app without having to search for it beforehand, with the sole purpose of figuring out the correct name.

I don't propose to enforce caskname rules at audit time.

Neither do I, we would not be able to do it even remotely efficiently anyway (in either approach).

I want to stop dupes such as #2571 and #2633 before they happen, patrolling for them is wasted time.

Now that, that one I will not contest in any way, and you’re absolutely correct. To me, that’s the strongest and most objective reason found in both approaches. I can really get behind that.

On another note, sometimes even the app’s website itself is inconsistent with what they call it (like Box Sync), so one of your initial points

The App name on disk is in any case superior to consulting the website, as it is less subject to misreading or artistic interpretation.

Is even more valid then. Between this and the previous point, I’m sold on it.

[rolandwalker]

@vitorgalvao , updated/squashed according to your v useful feedback.

Yes, cdto is written in both forms on the author site.

My plan is to achieve better Caskname standardization in 3-4 rounds. This is the simple round. I will definitely ping you on the next rounds as they are harder. But basically I don't care which side a rule falls on so long as we pick one.

This project's power and size comes from the "drive-by" Cask author who commits 1 or 2 Casks. I want to make it super easy/fast/fun for that person.

[rolandwalker]

OK. I'm going to move forward on this.

My ultimate goal is a script which suggests the cask name.