Deprecate brew (un)linkapps.

[MikeMcQuaid]

Unfortunately brew linkapps cannot behave nicely with e.g. Spotlight using either aliases or symlinks and Homebrew formulae do not build "proper" .app bundles that can be relocated. Instead, please consider using brew cask and migrate formulae using .apps to casks.

CC @ilovezfs as we've talked about this before.

[ilovezfs]

When this is actually removed, will it merit a bump to Homebrew 1.2.x?

[MikeMcQuaid]

When this is actually removed, will it merit a bump to Homebrew 1.2.x?

@ilovezfs Yes, most likely (although some will argue it warrants a bump to Homebrew 127.0.0.0.0.0`

[ilovezfs]

So does this imply, for instance, that the --with-cocoa option for emacs will be killed, or does it imply that the user will need to launch the .app from the Cellar directly?

[MikeMcQuaid]

It implies that it's not in keeping with Homebrew's general philosophy. As upstream provides no official alternative build I don't think we need to kill it as it's extremely widely used. Others can take this script and maintain it in a tap elsewhere, I just don't think we should be.

[ilovezfs]

The UX involved with navigating directly to a .app bundle in the Cellar seems worse than the status quo. Wouldn't it be better to remove all .app bundles than to actively create an even worse experience?

[MikeMcQuaid]

I think eventually: probably. By then we may end up distributing our own Casks built by CI or something.

[ilovezfs]

I think eventually: probably. By then we may end up distributing our own Casks built by CI or something.

Yeah. I think it's not going to be pretty telling people "so you need to press command + shift + G and then navigate to ...."

[MikeMcQuaid]

Sure. A while until then, though.

[BenjaminHCCarr]

Sorry to jump on this I just brewed and got the warning for the first time.
I build the IDEs for -core projects as well (and the GUI for mpv for my SO):

Warning: `brew linkapps` has been deprecated and will eventually be removed!

Unfortunately `brew linkapps` cannot behave nicely with e.g. Spotlight using
either aliases or symlinks and Homebrew formulae do not build "proper" `.app`
bundles that can be relocated. Instead, please consider using `brew cask` and
migrate formulae using `.app`s to casks.
Linking: /usr/local/opt/mpv/mpv.app
Linking: /usr/local/opt/python/IDLE.app
Linking: /usr/local/opt/python/Python Launcher.app
Linking: /usr/local/opt/python3/IDLE 3.app
Linking: /usr/local/opt/python3/Python Launcher 3.app
Linking: /usr/local/opt/qt5/libexec/Assistant-qt5.app
Linking: /usr/local/opt/qt5/libexec/Designer-qt5.app
Linking: /usr/local/opt/qt5/libexec/Linguist-qt5.app
Linking: /usr/local/opt/qt5/libexec/pixeltool-qt5.app
Linking: /usr/local/opt/qt5/libexec/qml-qt5.app
Linked 10 apps to /Applications

Does this mean that for PythonX and QT I will need to install the environment from -core and the IDE's from Cask? Or will the formulas now actually move the .app instead of linking?

Sorry, the warning doesn't give a lot of detail, it might be helpful to throw a page up about what is going on that is printed in the warning.

Also as mentioned in Homebrew/homebrew-cask#28988, mpv is more than a gui, it's a fork of mplayer-something, it is both a CLI and a GUI and they serve very different purposes. I stated with mplayer on linux shortly after 640kb was enough as a CLI. I started using MPlayerX and it's successors later when UX for SO's became more important. In all reality if I was to watch something I had ripped I would cd $MOVIES and mpv file_name.mkv. While others would use finder.

This says linking is dying, does that mean that we are changing the built .app to /Applications or even go back to ~/Applications. Or that -core will no longer build .app's at all? This may be particularly significant in -science as we may need to build OpenMP or use your own -L for your fortran, etc for a GUI frontend.

[MikeMcQuaid]

This says linking is dying, does that mean that we are changing the built .app to /Applications or even go back to ~/Applications. Or that -core will no longer build .app's at all? This may be particularly significant in -science as we may need to build OpenMP or use your own -L for your fortran, etc for a GUI frontend.

This means that you'll need to make any symlinks or aliases manually yourself and we're likely to remove GUIs in the long-term from homebrew/core.

[BenjaminHCCarr]

This means that you'll need to make any symlinks or aliases manually yourself and we're likely to remove GUIs in the long-term from homebrew/core.

1. Would you be amenable to a standardized caveat in that case?
2. I am concerned about name-collision with cask and core. Will mpv be removed from core? or will the CLI system stay intact and the bundler just move along, and be replaced by an mpv cask? But one will be brew mpv and one brew cask mpv?

[MikeMcQuaid]

Would you be amenable to a standardized caveat in that case?

I don't think so as it'd be the same effect as brew linkapps: stating we support a use-case we don't/can't well.

I am concerned about name-collision with cask and core. Will mpv be removed from core? or will the CLI system stay intact and the bundler just move along, and be replaced by an mpv cask? But one will be brew mpv and one brew cask mpv?

I believe name collisions are being updated to be e.g. mpv-app.

[vitorgalvao]

I believe name collisions are being updated to be e.g. mpv-app.

Only in specific cases (emphasis added):

If a Homebrew formula and a Homebrew-Cask cask both exist with the same token and they both refer to the same app — respectively a CLI and a GUI — and the GUI app is simply a wrapper of the CLI tool but has been decided to provide enough value to warrant the inclusion of both the formula and the cask, the cask will have the -app suffix. This is the only instance where an -app suffix is allowed, precisely so the “why” is clear when you know the rule.

I don’t consider the mpv GUI to be a simple wrapper on the CLI (after all even the CLI calls a GUI). Another notable example is transmission. The CLI version is considerably less known than the GUI, adding -app to the GUI version would not make sense.

[BenjaminHCCarr]

ah, I didn't realize that we had a transmission and a cask/transmission as well; and that this is already handled well by the codebase. I agree with @vitorgalvao that in both cases the GUI is more than a qt/gtk/etc front end, and that they are distinct.

I also see that most people that want "something" will likely want the GUI, and that the mpv.rb will live on like transmission and handbrake before it (the three I could think of where I use both that aren't just frontends).

[MikeMcQuaid]

Only in specific cases (emphasis added):

@vitorgalvao Apologies for the bad explanation and thanks for chiming in.

I also see that most people that want "something" will likely want the GUI, and that the mpv.rb will live on like transmission and handbrake before it (the three I could think of where I use both that aren't just frontends).

I agree in which case we should prioritise Cask over Homebrew. I realise the transition isn't going to be terribly pleasant but we need to get the basic idea that Homebrew is where you look for open-source command-line applications and Homebrew Cask is where you look for closed-source and/or GUI applications.

[ilovezfs]

I'd much prefer we just deconflict these names rather than having these ongoing discussions about what should be the default when the names collide, which we should just make impossible.