Feature: Track Mac App Store apps with Cask metadata

[jasonkarns]

Should there be a different workflow, or perhaps some notice given for apps that are available through the App Store?

It could be as simple as a predefined caveat that is announced when an app is installed/upgraded. But I think it makes the most sense to move apps into a different tap, if they are available through the app store. I prefer to have apps installed through the App Store, as primary source, if they are available. My second choice is brew-cask. Having a second tap would mean that doing a brew-cask search would show the app, but listed under the app-store tap would make it clear that I can install it through the App Store instead.

Thoughts? Other approaches for tagging/segmenting app-store apps separately?

[vitorgalvao]

We simply do not allow Mac App Store-only apps (meaning commercial apps that can only be bought through there do not have trials available here).

Separating apps that are available both through the MAS and direct download doesn’t bring much and takes away a lot. Having to tap a separate repo for no good reason (if you don’t care about if an app is available through the MAS) is simply confusing, as some apps would have to be moved there and removed from the main repo. We’re not a discoverability service (this has been discussed many times in the past) — you should have some knowledge of the app you’re installing before doing so.

This change would put an unnecessary burden on maintainers with close to no gain but with big disadvantages.

[jasonkarns]

Any chance to leave this open for some more discussion? I'm not only
interested in a separate tap. I'd be open to any other ideas. (Like I
suggested, some sort of tagging option or automatic caveat notice.)

On Mon, Feb 2, 2015 at 11:56 AM, Vítor Galvão [email protected]
wrote:

Closed #9384 #9384.

—
Reply to this email directly or view it on GitHub
#9384 (comment).

[phinze]

Thanks for the question, @jasonkarns.

I prefer to have apps installed through the App Store, as primary source, if they are available.

Unfortunately I think you're in the minority here. The MAS is sort of our sworn enemy - it's relentlessly opaque and un-automate-able.

When we find apps available solely through MAS, we often try to work with dev teams to get them to also publish a non-MAS version so that we can include it here. For me personally, when I see an app that only publishes on MAS, I cry bitter, bitter tears. 😭 😭 😭

If you'd like to pursue a plugin that adds metadata about MAS by parsing Casks, then you're very much welcome to do so. I'm sure we'd be willing to list this plugin as available. But if you're looking for a first-class feature that points users at MAS, I think we'd probably take some convincing that there's enough user interest for it to be worth it.

Breaking it down into the metadata I think you'd care about:

• Cask field that indicates "Also available in MAS"
• A stub Cask that tells user "This app is only available in MAS, go yell at the devs here"

I'm cool to leave this open for a bit to see if there are other users who'd care about something like this.

[jasonkarns]

Good to know your position on MAS.

I was originally against the MAS, but it won me over with easier
auto-updating and keeping apps synced across machines. I personally love
brew-cask but only in so far as a replacement to downloading zips and dmgs.
But I might reconsider my stance when brew-cask gets the upgrade feature
worked out.

If I'm in the minority w.r.t. MAS, I'll kindly retract. :)

On Mon, Feb 2, 2015 at 12:03 PM, Paul Hinze [email protected]
wrote:

Thanks for the question, @jasonkarns https://github.com/jasonkarns.

I prefer to have apps installed through the App Store, as primary source,
if they are available.

Unfortunately I think you're in the minority here. The MAS is sort of our
sworn enemy - it's relentlessly opaque and un-automate-able.

When we find apps available solely through MAS, we often try to work with
dev teams to get them to also publish a non-MAS version so that we can
include it here. For me personally, when I see an app that only publishes
on MAS, I cry bitter, bitter tears. [image: 😭] [image: 😭] [image:
😭]

If you'd like to pursue a plugin that adds metadata about MAS to existing,
then you're very much welcome to do so. I'm sure we'd be willing to list
this plugin as available. But if you're looking for a first-class feature
that points users at MAS, I think we'd probably take some convincing that
there's enough user interest for it to be worth it.

Breaking it down into the metadata I think you'd care about:

• Cask field that indicates "Also available in MAS"
• A stub Cask that tells user "This app is only available in MAS, go
  yell at the devs here"

I'm cool to leave this open for a bit to see if there are other users
who'd care about something like this.

—
Reply to this email directly or view it on GitHub
#9384 (comment)
.

[vitorgalvao]

Unfortunately I think you're in the minority here.
(…)
we'd probably take some convincing that there's enough user interest for it to be worth it.

Precisely. I’ll reiterate:

This change would put an unnecessary burden on maintainers with close to no gain but with big disadvantages.

As for the recommended suggestions

Cask field that indicates "Also available in MAS"

Do we really want to add another field? Contributions are already becoming harder to include on the first try. Each field introduces a new point for mistakes, and requires more back and forth to fix. Is yet another message a good idea at all (precisely what we’re discussing in #9229)?

A stub Cask that tells user "This app is only available in MAS, go yell at the devs here"

I believe this is a recipe for user confusion and, to an extent, harmful to developers. Many developers distribute apps exclusively via the MAS for very good reasons like limitations on distribution on their country, and server costs or legal fees associated with distribution. It’s one thing to talk to developers about features that make the app unusable in situations where it should be (like some apps called from outside /Applications), but pressuring them to take extra work, extra time, extra resources, and extra money to satisfy a few people, contrary their wishes, can really be taken the wrong way.

This is a feature that will serve a very small minority, place more work on maintenance, and be neglected¹ or wrong in many casks (starting from the moment it’d be implemented).

Many apps have already been removed because they became MAS-only. Unfortunately most of these are only discovered when making unrelated en masse changes, which isn’t sustainable in the long run. If it’s hard enough to keep up with casks that are no longer available via direct download (which is what this whole project is all about), we can’t really expect to keep up with distribution models apps use.

As has been pointed out many times before, many of our contributions are from first-time contributors. That is exceptional in a way, but it also means we have a bunch of “submit and run” casks that are never updated, causing a bad experience and as a result need to be removed. New features that add information should be considered with this in mind. licenses mostly don’t change, as don’t names, or deprecation. Distribution models do much more often (as exemplified by casks that become MAS-only).

---

¹ We don’t even have the necessary java caveats, as well as name and license stanzas, implemented in all the casks that need it, and some of these are mandatory (license), or required for an acceptable experience (java).

[phinze]

Yikes. Okay, clearly you feel very strongly about this, Vitor. Based on the tone you're chosen to take here, it feels like maybe you have some deeper unexpressed concerns about the project. I'll follow up with you via email.

In the meantime, I'll close this, since after that message I don't think there's much more useful conversation that can be had on this thread.

[vitorgalvao]

Based on the tone you're chosen to take here

I sincerely apologise on that note (and to you as well, @jasonkarns), as it wasn’t my intention to have a confrontational tone. I should have reread the comment with more attention before posting. It is in clear need of editing.

To be clear, I’m not implying any big underlying issue. My concern is that this is one of those features we have no reasonable expectation of supporting adequately, and that would make the project worse in the long run.

[jasonkarns]

@vitorgalvao No offense taken. :)

And, to be clear in my intent, I wouldn't suggest that MAS-only apps be added to the caskroom. My intention is to make it aware to users when an app that is already in the caskroom (or already installed) is or has become available in the MAS.

The instigation for this for me was the Slack app. I had installed Slack through cask a while back - well before they were in the MAS. At that time, the slack app installed via cask was unable to auto-update. Even just today, the cask-installed version of slack would indicate there were no updates (through the app's update mechanism, not cask's), when in fact it was not the latest version available from MAS. I've since uninstalled Slack through cask and installed the latest from MAS. My rationale for this change is that a) developers who do distribute through the MAS will consider the MAS as the primary distribution channel and b) as such, the MAS will always have the latest versions available. Thus, as a user, I would consider MAS to be the canonical source for the app and would prefer to have cask notify me when a cask-installed app becomes distributed through MAS.

If a) the upgrade story changes such that cask upgrades are as easy/smooth as MAS; or b) if the majority of the cask community prefer cask as the canonical app source, then the MAS notification wouldn't make as much sense. However, (a) is not currently the case and (b) is contentious given that many app devs must be persuaded to publish their app outside of MAS.

When we find apps available solely through MAS, we often try to work with dev teams to get them to also publish a non-MAS version so that we can include it here.

Of course, the level of effort to create the feature, and to keep the cask formulas updated is certainly a major strike against the viability of it. :)

As an alternative, would the cask maintainers be welcoming of one-off PRs to each of the MAS-available formulas that simply adds the caveat note that the app is available in MAS? (ie, without an automatic feature or plugin, but just manual notice per formula)

[tapeinosyne]

I was originally against the MAS, but it won me over with easier auto-updating and keeping apps synced across machines.

Indeed, homebrew-cask will never enjoy the degree of integration that can be achieved with the MAS. Auto-upgrading would be trivial, but functionality like sync would need to be deferred to custom setups of varying complexity. No such setup would be as appealing as a native system.

Should there be a different workflow, or perhaps some notice given for apps that are available through the App Store?

You are right in that this would be desirable. However, the required bookkeeping would be onerous, and (I suspect) serve the interest of few users.

Beyond that of immediate practicality, there is another concern, more philosophical in nature: the goal of homebrew-cask is to be a package manager of sort, and tracking information concerning third-party services is outside our scope. (Allow me to make an even broader point, half-facetiously: what CLI utility kindly informs you of the state of a “rival” tool, just in case you would rather be using that?)

[floam]

Not really necessary to track the information - one could programmatically search using bundle_id and get returned JSON indicating if and what version is on MAS. ie. https://itunes.apple.com/lookup?bundleId=com.codeux.irc.textual5