Deprecate brew (un)linkapps. #1808

Merged
merged 2 commits into from Jan 11, 2017

Projects

None yet

4 participants

@MikeMcQuaid
Member

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
Member
ilovezfs commented Jan 9, 2017

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

@MikeMcQuaid
Member

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
Member
ilovezfs commented Jan 9, 2017

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
Member

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
Member
ilovezfs commented Jan 9, 2017

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
Member

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

@ilovezfs
Member
ilovezfs commented Jan 9, 2017

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
Member

Sure. A while until then, though.

MikeMcQuaid added some commits Jan 9, 2017
@MikeMcQuaid MikeMcQuaid Deprecate brew (un)linkapps.
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.
f5b63f4
@MikeMcQuaid MikeMcQuaid caveats, keg: remove linkapps caveats code.
c0a29d6
@MikeMcQuaid MikeMcQuaid merged commit ebf3d93 into Homebrew:master Jan 11, 2017

3 checks passed

codecov/patch 100% of diff hit (target 63.06%)
Details
codecov/project Absolute coverage decreased by -0.01% but relative coverage increased by +36.93% compared to 9cce341
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@MikeMcQuaid MikeMcQuaid deleted the MikeMcQuaid:deprecate-linkapps branch Jan 11, 2017
@vitorgalvao vitorgalvao referenced this pull request in caskroom/homebrew-cask Jan 13, 2017
Closed

Readd mpv #28988

@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 caskroom/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.

@DomT4 DomT4 referenced this pull request Jan 15, 2017
Open

brew cask add upgrade/outdated/pin/unpin #1523

4 of 5 tasks complete
@MikeMcQuaid
Member

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
Member

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
Member
vitorgalvao commented Jan 16, 2017 edited

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
Member

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
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment