change default install location for apps to /Applications

[vitorgalvao]

Closes #2534.

Pending agreement.

[Amorymeltzer]

Please excuse me if I'm mistaken, but lines 185-186 of USAGE.md state:

This is commonly used to create the links in the _root_ Applications directory instead of the _home_ Applications directory by specifying...

Shouldn't _root_ and _home_ be swapped here?

[vitorgalvao]

You are very right. Thank you. Fixed.

[rolandwalker]

While I am loathe to change the defaults, I am generally swayed by the number of requests.

However, let's analyze this a bit first for unexpected effects:

• The assumptions behind info: add requires_sudo? and --machine-readable #8819 may become incorrect, and there may be other similar code.
• brew cask info may show incorrect info, as the existing symlink is in an unexpected place.
• Uninstalling an app would leave behind the broken symlink in the old default location.
• Using the system-wide dir for Apps, and keeping the user dir for ~/Library artifacts is inconsistent and extremely confusing.

There may be more issues, as I haven't thought deeply. Any change would have to be done carefully.

[jawshooah]

• brew cask info may show incorrect info, as the existing symlink is in an unexpected place.
• Uninstalling an app would leave behind the broken symlink in the old default location.

This can be remedied by exposing more information about cask installations in the .metadata directory. Perhaps a simple JSON file:

{
  "appdir": "~/Applications",
  "binarydir": "/usr/local/bin",
  ...
}

[vitorgalvao]

Using the system-wide dir for Apps, and keeping the user dir for ~/Library artifacts is inconsistent and extremely confusing.

I disagree, as this recommended change is due to a matter of expectations. Users expect apps to be global (/Applications) and other things to be local (~) because instructions for things other than apps (unless they come in a pkg) usually tell you to install in the user directories.

Inconsistent? Perhaps. Confusing? Quite the contrary. We’ve seen many users (not just in that issue) question the choice of ~/Applications but never the other directories. The current setup is the confusing one, which is why most change it.

With all the other points I mostly agree — we should take some care to not break things too much. My primary concern was making a decision, whichever it is, and close the issue (we have too many under consideration that we should just pick something).

However, I don’t really think issues like orphaned links on uninstall are a problem; especially if we consider most users are indeed already picking /Applications as the links directory. I say that because they’re at worst a minor annoyance. I also agree with @jawshooah with exposing more information in .metadata, though that should be discussed in depth in another issue.

I also appreciate all the care we always take with transitions, and we should indeed be careful considering the considerable user-base we have, but we’re admittedly pre-alpha: things are expected to and should break; now is the only time we get to not be shy about that.

[jawshooah]

we’re admittedly pre-alpha: things are expected to and should break; now is the only time we get to not be shy about that.

I keep forgetting about this. Most things work very nicely, so it's easy to forget that this project is still in its relative infancy.

[rolandwalker]

@vitorgalvao beautifully argued as always, and you have me convinced in principle about making an incompatible change.

In practice, we are in heavy use. In practice, we also have to respond to issues. There are likely near 100 duplicate reports regarding the recent incompatible change with Homebrew.

That bug was fully addressed within a few hours. Every user who upgraded outside that small time window never saw the bug, and never filed an issue.

But the appdir change is different: instead of affecting a subset, it will affect every single user going forward. And there is no "notice of incompatible" change when people upgrade at the CLI. Thus it has the potential to generate truly enormous numbers of duplicate issues.

And that must be reckoned with, regardless of what version number we assign to ourselves.

[phinze]

Great discussion here so far. I'm +1 for changing the default, but I'd like to continue to discuss options for smoothing out the transition a bit more before we just decide to do a "damn the torpedoes" merge.

And there is no "notice of incompatible" change when people upgrade at the CLI.

We could special case this with a message printed to users that do not have the appdir explicitly configured (or even just throw in a notice to everybody, billboard style). We'd just have to decide on how to approach the messaging.

Besides the details, are we mostly agreed that messaging to the user base for this change is worth pursuing?

[vitorgalvao]

@rolandwalker Well, you do tend to be able to make me take a step back and see what I missed in these major decisions.

I do stand by the point that this change (as opposed to the incompatibility one) would be “at worst a minor annoyance”. The former broke the complete experience, while the latter might cause slight confusion (annoyance, perhaps?). The number of users it’ll affect may also be extremely reduced, if we assume most are using /Applications as the linking directory anyway (which we can’t say for sure).

However,

Thus it has the potential to generate truly enormous numbers of duplicate issues.

And that must be reckoned with (…)

This possibility is certainly not something that can be ignored, I agree.

Besides the details, are we mostly agreed that messaging to the user base for this change is worth pursuing?

@phinze Yes.

Would it be worth considering an abstraction of such a system? Something that we could use in the future when making breaking changes. Could we in theory perhaps take more control over homebrew-cask upgrades, so that upgrading normally from a pre-break version to the new one would be stopped until the user is aware of the modifications? I’m guessing not currently, as long as brew upgrade brew-cask works.

[rolandwalker]

Could we in theory perhaps take more control over homebrew-cask upgrades

No, that's the problem. The moment that the upgrade happens is out of our control. We'll have to look at the first execution after the upgrade.

Messaging is good, and we should do it, but it's not sufficient. Some people will be running the command from a script.

Some finesse may be in order. After all, we managed #4688 with very few hitches. The key was to overlap functionality for a while and sweep up afterwards.

What about:

• implement brew cask activate <cask> to help people control the switchover
• at install time
  • check whether --appdir was set explicitly
  • check for symlinks in ~/Applications
  • if there are symlinks that belong to us in ~/Applications, and --appdir was not set
    • create the new symlink in both places
    • emit a warning that explains how to complete a clean switchover

Another possibility would be to grab any symlinks that belong to us and re-create them in both locations. Then the user would only need to rm them from ~/Applications to make the warning go away.

[vitorgalvao]

Both options seem acceptable to me. The second one could mean a faster transition, though.

I don't understand what brew cask activate <cask> is supposed to be doing.

[rolandwalker]

Sorry: the activate verb is meant to be like brew link, only generalized for copying, linking or shimming.

For this case it would just mean "regenerate the symlinks for my staged Cask".

[tapeinosyne]

As original promoter of the pesky #2534, I am unsurprisingly in favor.

However, @rolandwalker is right in recommending to approach sweeping changes with caution (and a beekeeping suit). Perhaps reformed defaults would be best postponed to an official beta release, where users may be more tolerant of incompatible behavior.

[nylen]

Cross-posting from #2534 (comment):

Another 👍 for /Applications as default. It looks like Apple is trying to phase out support for ~/Applications, and cask should follow Apple's lead.

I just want all of my installed applications to show up in the Applications stack in the dock. I don't care about the rest. For now, I'm accomplishing that using the line in .bashrc mentioned above:

export HOMEBREW_CASK_OPTS="--appdir=/Applications"

I shouldn't have to worry about things like that, it should just work ;)

[wamatt]

Can we go ahead and merge @vitorgalvao commit? What's the hold up?

[vitorgalvao]

What's the hold up?

We need a strategy for a smooth transition.

[basnijholt]

Any updates on this?

[vitorgalvao]

Same issue.

[basnijholt]

You linked this issue?

[vitorgalvao]

I linked my previous response to that same question.

[vitorgalvao]

Redundant due to the news on #13201.