Search results indicate app store non-cask apps

[focusaurus]

Suggestion for brew cask search to list specific casks that are known but will not be added to the official repo due to the trial version/app store policy.

I started to build a cask for BusyCal before I found the policy about App Store re-downloads and researched to discover BusyCal would fall under that category. My suggestion is that brew cask search busycal report something like BusyCal is not available as a cask. Please purchase and install via the Mac App Store or something along those lines with a link to the app store page and relevant cask docs on the policy perhaps.

[tapeinosyne]

Hello @focusaurus.
This is a good idea, per se, but I feel that its cost is too high: we would either need to scrape and correlate a large amount of data, or manually maintain an index of known exceptions.

Either approach is unworkable. A simpler, more efficient solution would be to improve the documentation by making our policy more prominent. Perhaps brew cask create could print a notice before launching the editor?

[focusaurus]

Well it seems to me an app_store.yml file with the names of such apps would do it, and maintain it the same way this entire project works - community contributions, but as a newcomer I have to respect your opinion of what is unworkable.

I'd vote for adding output to brew cask search when no matches come back explaining that this could mean either the app has not been caskified or it cannot be caskified due to the app store trial policy. I think waiting until brew cask create is wasting end user time, but again this is just a suggestion for discussion.

[tapeinosyne]

We are fairly adamant about not wasting end users' time, which means that your suggestion is very welcome.

An app_store.yml would be the ideal solution, but I fear that it would be unlikely to reach sufficient coverage. Unless the user were confident that the exclusion list is nigh-infallible, they would still need to manually verify the admissibility of their application.

Consider a hypothetical scenario in which we reach the ridicolously high inadmissibility coverage of, say, 90%. You brew cask search an app, and the results state that it is neither available nor inadmissible. You would like to contribute this new app, but there is still a 1/10 chance that it is inadmissible. If you are scrupulous, you verify, and app_store.yml has been of little use to you; if you are unscrupulous, you submit without verifying, which we must, and we end up rejecting ~1/10 of such PRs.

Users who search for a known inadmissible cask would save a few seconds, but I am not persuaded that such a small benefit would be worth the maintenance burden (on both core team and contributors).

On the other hand, adding a notice to brew cask search, as you suggest, would be a trivial change with immediate benefits. I agree that we should improve the output of failed searches.

[focusaurus]

Unless the user were confident that the exclusion list is nigh-infallible, they would still need to manually verify the admissibility of their application.

I think we are conceiving the primary beneficiary user of this feature differently. I'm thinking about the case of:

• User wants to install an app, let's use my example of BusyCal which is both fairly popular and inadmissable
• brew cask search busycal states clearly that cask is aware of BusyCal and it is inadmissable. Tells user to purchase via the App Store.
• user sees that and goes to the App Store. End of story.
• as opposed to the user having to then do the research to figure out if is BusyCal missing because no one has built a cask for it or they made a typo in their search query or brew cask search's fuzzy matching wasn't right or or because it is inadmissible
• another way to think about this is that once ONE member of the community has done the research to learn that an app is inadmissible, I think that knowledge should be codified and shared. I realize there is effort to that, but a PR on the order of echo busycal >> app_store.yml seems worthwhile to me. But you may be right that the effort is too high.

It sounds like you are conceiving of the primary user as someone intent on caskifying the app in question, which I think is a smaller percentage compared to users who use brew cask without ever intending to build and contribute a cask spec.

I don't think the total comprehensiveness of the exclusion list has much bearing on it's worth. If we get the top 100 most common app store apps in there, we're saving many many people time and frustration on an ongoing basis. After that, it's a long tail but there's a lot of bang for the buck of the first 100 lines in that file IMHO. This could also be driven by metrics by looking at the search queries or github issues and seeing if anything comes up often enough to warrant adding it explicitly.

OK, I'll leave it to your discretion from here. Thanks for your attention.

[rolandwalker]

@focusaurus thanks for the suggestion! Your thoughts are very welcome. I also hate wasting time.

Someone might try to work on this idea, and PRs are welcome. However, it is worth noting that no other package managers have similar functionality, and worth thinking about why.

The top 100 apps would indeed have the most bang. However, the number of excluded apps is much larger than the number of included apps. So, theoretically, app_store.yml can become a larger project than Cask itself.

• We'd need to have some kind of strict limits on app_store.yml.
• We'd also have to manage name collisions between app_store.yml and regular Casks. Any name in app_store.yml would have to be disqualified as a Cask name.
• To resolve name collisions, we'd need to keep a URL or some other identifying information in app_store.yml, and probably also the issue number where the Cask was denied.
• We would have to add some audit-testing code to guard against the collisions.
• We would even need to track when upstream changed the app name.

It would end up being a fair amount of work. That doesn't mean it is impossible, but at minimum I reckon somebody would have to join the project with a mission to handle this area.

The strongest point in favor of your proposal is that we are currently throwing away information. It is present in GitHub in the form of closed pull requests, but there are so many closed PRs — there's not a very friendly interface to that data.

[muescha]

if rejected issues are tagged with the reason then it can be searched with that tag filter

empty search results should have a link to a wiki page with a "why my app is not listed here?"
in that wiki there is a link to the rejected issues and an explanation of the rules.

[focusaurus]

However, it is worth noting that no other package managers have similar functionality, and worth thinking about why.

This is debatable. I think that the realities of different OSes and ecosystems prohibit compare/contrast arguments along these lines. I'd argue that both the deb and rpm systems are so overwhelmingly comprehensive that many running systems consist entirely of packages from the package manager plus a very small handful of custom or in-house applications. This use case does not directly apply to those systems in my opinion. They are almost entirely open source with permissible licenses and dedicated teams working tirelessly for years to create and maintain a comprehensive and robust package ecosystem. And Windows is another thing entirely. And language-specific package managers are another thing entirely. Honestly I think the Mac App Store/homebrew situation is unique and I see no analog on any other platform or package ecosystem. Or to address the "thinking about why" clause: deb/rpm - the system is comprehensive and mature. Exceptions are truly exceptional (oracle). Android/iOS - no viable alternative exists. If you don't find it in the app store, you're pretty much SOL. Windows - who knows ???.

That said I want to note that Ubuntu has Command Not Found Magic system with this goal of discoverability, usability, and pointing users in the right direction without any issues being filed, pull requests, desperate web search sessions, etc.

What I think might actually get implemented in homebrew based on this conversation is an extra sentence or two printed to the console along with the results of brew cask search. I think that is low-effort and high-reward. Here's my suggested text:

Some applications available through the Mac App Store are not compatible with homebrew-cask due to trial versions requiring a reinstall after purchase or other technical or licensing restrictions. If you do not find your package through a cask search, this may be why.

Aside from that I'd say let's just keep this in mind as an option in the future as the list of closed PRs grows.

[tapeinosyne]

It sounds like you are conceiving of the primary user as someone intent on caskifying the app in question, which I think is a smaller percentage compared to users who use brew cask without ever intending to build and contribute a cask spec.

Yes, in a sense: I am assuming that the non-contributor has no interest in why an app is not casked, and will just move on and install from elsewhere.

[vitorgalvao]

I’ve reread the whole issue, and it seems no actual decision has been made. We should either refuse the idea and close this, or accept it, close this, and create a new issue outlining what needs to be done.

As someone who reads every issue and submission, I don’t think this is such a big issue, and the MAS rule seems to be fairly well known amongst contributors, even new ones. Realistically, perhaps most contributors don’t read through CONTRIBUTING.md, but they really should, especially since we have a section named “finding a home for your cask”, with the policy on MAS apps clearly stated.

There seems to be consensus that maintaining a file referencing every app that shouldn’t be included is more trouble than it’s worth, but the alternative — printing a generic message every time a user doesn’t find something — seems nonsensical, to me: we’d just be rehashing what’s in the documentation already. Sure, some things need to be explicit in more than one place for the benefit of the user, but if we start adding every possibility, every “this might happen”, the user will be overwhelmed with messages and will care for none of them. We have to draw the line somewhere — the rule is stated clearly under the appropriate section, on the document accessible every time the “New issue” button is clicked, that is on the root of the project, with a standard name for github projects, in all caps. What more can we ask, here? Some rules are more important than others, and judging by the huge decline in submissions of MAS apps, this one seems very well covered.

I’ll close the issue on those grounds, but if any other maintainer disagrees, please reopen it so we can outline the next steps we need to take.