emacs migrated to cask

[AnastasiaSulyagina]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same formula update/change?

---

Deleting emacs from homebrew-core as part of deduplication process . See context here.

Please note that this PR is created to continue case-by-case discussions from thread linked above and if decision is made not to remove the formula, PR will be closed.

[DomT4]

Crossposting myself here: #3333 (comment)

[MikeMcQuaid]

I think in this case we could consider removing X11 and/or Cocoa options in favour of the Cask for them as we still build a CLI by default (I believe?)

[MikeMcQuaid]

To differentiate these we could consider renaming formulae like this to emacs-cli (and/or maybe rename the cask to emacs-gui)?

[zmwangx]

Again I find this unacceptable. To reiterate (on Homebrew/homebrew-cask#15603 (comment)),

1. CLI-only Emacs (as bottled) works perfectly fine and is used by many.
2. emacsforosx.com is NOT the official build, and the GNU Emacs project does NOT distribute official binaries. You can't remove the official build option in favor of a third-party binary distribution.

I think renaming the cask to emacs-gui might be a good idea.

[zmwangx]

I think renaming the cask to emacs-gui might be a good idea.

Or emacs-app maybe, taking a page from MacPorts (see https://www.gnu.org/software/emacs/download.html).

[DomT4]

I think in this case we could consider removing X11 and/or Cocoa options in favour of the Cask for them as we still build a CLI by default (I believe?)

I'm a pretty big 👎 on removing at least cocoa, to be honest. Care less about X11 because X11 is generally painful for everyone involved. I really want to avoid the situation where we make people brew install emacs for the CLI & brew cask install emacs for the GUI or some combination thereof.

We don't really handle that sort of divorce well. We remove the options, the next time people rebuild they get an unexpected vanilla CLI emacs and come moan at us asking what changed... Or we add something to tap_migrations that hasn't actually been migrated.

[zmwangx]

Sorry for not keeping my comments as one...

I think in this case we could consider removing X11 and/or Cocoa options in favour of the Cask for them as we still build a CLI by default (I believe?)

That of course comes with the (big) catch that people can no longer install devel and HEAD versions of Emacs.app, because cask only provides emacs and emacs-nightly at the moment (nightly != HEAD).

Also, expect friction as many people are probably used to brew install emacs --with-cocoa by now (it's even on https://www.gnu.org/software/emacs/download.html). (Already covered by @DomT4 before I published this post.)

Does --with-cocoa generate a lot of support burden?

[MikeMcQuaid]

emacsforosx.com is NOT the official build, and the GNU Emacs project does NOT distribute official binaries. You can't remove the official build option in favor of a third-party binary distribution.

I'm confused about "official build option" considering the GNU Emacs site links to both brew install and the emacsforosx.com site.

[dunn]

The GUI options are used by at least half of the install base, right? If we're dead-set on removing GUI apps from core, I'd rather the entire formula be migrated to the Emacs tap.

[MikeMcQuaid]

We don't really handle that sort of divorce well. We remove the options, the next time people rebuild they get an unexpected vanilla CLI emacs and come moan at us asking what changed...

Yes, we may need some DSL that expresses than an option has gone away and tells people what to do instead.

I really want to avoid the situation where we make people brew install emacs for the CLI & brew cask install emacs for the GUI or some combination thereof.

If the goal of bringing Homebrew and Cask closer together is to reduce or remove the number of .apps we have in Homebrew: isn't this somewhat inevitable? What would you propose instead? I think https://github.com/Homebrew/brew-evolution/pull/3 helps highlight some of the various problems we have with the status quo.

[MikeMcQuaid]

The GUI options are used by at least half of the install base, right? If we're dead-set on removing GUI apps from core, I'd rather the entire formula be migrated to the Emacs tap.

Another option we could consider is migrating only users of particular options to the casks. I think the (my) long-goal is to have basically everything that builds or handles an app be a Cask rather than a Formula so we can remove all code like e.g. linkapps from Homebrew.

[zmwangx]

emacsforosx.com is NOT the official build, and the GNU Emacs project does NOT distribute official binaries. You can't remove the official build option in favor of a third-party binary distribution.

I'm confused about "official build option" considering the GNU Emacs site links to both brew install and the emacsforosx.com site.

In case I wasn't clear, emacsforosx.com and brew install emacs --with-cocoa are both third party solutions — emacsforosx.com listed alongside (and below) brew install reinforces the fact that it is unofficial. For an Emacs binary to be official it has be hosted by gnu.org on ftp.gnu.org.

However, downloading the source tarball from ftp.gnu.org and run ./configure --with-whatever-options, make, make install is the official build option, and brew install --build-from-source emacs --with-whatever-options is just a wrapper around the official option.

[MikeMcQuaid]

In case I wasn't clear, emacsforosx.com and brew install emacs --with-cocoa are both third party solutions — emacsforosx.com listed alongside (and below) brew install reinforces the fact that it is unofficial. For an Emacs binary to be official it has be hosted by gnu.org on ftp.gnu.org.

I see 👍

However, downloading the source tarball from ftp.gnu.org and run ./configure --with-whatever-options, make, make install is the official build option, and brew install --build-from-source emacs --with-whatever-options is just a wrapper around the official option.

I partially agree here but I do think there's a difference when we're running this for people and distributing binaries (not for this option, I'll admit).

[DomT4]

If we're dead-set on removing GUI apps from core, I'd rather the entire formula be migrated to the Emacs tap.

This tosses out our policy of not accepting cross-tap dependencies in core though, unless you also wanted every formula with a recursive emacs dep there as well. That would be a serious policy change to Homebrew.

If the goal of bringing Homebrew and Cask closer together is to reduce or remove the number of .apps we have in Homebrew: isn't this somewhat inevitable? What would you propose instead? I think Homebrew/brew-evolution#3 helps highlight some of the various problems we have with the status quo

I think this is too black-and-white, at least right out of the gate. I think primarily CLI applications with an optional GUI element are reasonable, and I think it's reasonable to say Homebrew isn't the place for pure .apps. I think we're going to seriously degrade UX if we immediately cut an arbitrary line in the sand here.

I think, generally speaking, expecting users to install both CLI & GUI separately is really crappy UX where we already offer a formula option to install that GUI.

If you want to go down that route particularly I'd like to see us implement a mechanism where brew install emacs --with-cocoa triggers a vanilla brew install emacs & then triggers brew cask install emacs. Essentially depends_on :cask => "emacs" if build.with? "cocoa" or such.

Although in this case that's not even a good example because the Cask emacs isn't an official one.

[MikeMcQuaid]

I think this is too black-and-white, at least right out of the gate. I think primarily CLI applications with an optional GUI element is reasonable, and I think it's reasonable to say Homebrew isn't the place for pure .apps. I think we're going to seriously degrade UX if we immediately cut an arbitrary line in the sand here.

Sorry, to be clear: let's try and figure out what perfect looks like and then work our way back and figure out how to get there.

I think, generally speaking, expecting users to install both CLI & GUI separately is really crappy UX where we already offer a formula option to install that GUI.

If the existing GUI doesn't provide some sort of CLI: I'd be surprised if the same users are using both.

[MikeMcQuaid]

To be clear on my comments though: more contentious formulae like this will be the last to be migrated. I'm in no rush, here.

[dunn]

This tosses out our policy of not accepting cross-tap dependencies in core though, unless you also wanted every formula with a recursive emacs dep there as well. That would be a serious policy change to Homebrew.

Ah, right.

[ilovezfs]

I think it's fine to bar .app/GUI options from ever being the default in core, but categorically ruling out non-default .app/GUI options seems like a rather obvious mistake.

[ilovezfs]

Another option we could consider is migrating only users of particular options to the casks. I think the (my) long-goal is to have basically everything that builds or handles an app be a Cask rather than a Formula so we can remove all code like e.g. linkapps from Homebrew.

That would be acceptable if Cask gets a build-from-source/build-bottle feature, which doesn't seem insane to me if there's truly going to be more integration.

[zmwangx]

Another thought about --with-cocoa, might have been brought up before: what about forgoing linkapps but leaving the option as is, and mention the app bundle in the caveat, like

If you built emacs --with-cocoa, you can find Emacs.app in $(brew --prefix emacs), and you might want to symlink it to /Applications by running

ln -s "$(brew --prefix emacs)/Emacs.app" /Applications

or, if people are concerned about the issues discussed in https://github.com/Homebrew/brew-evolution/pull/3,

..., you might want to move it to /Applications by running

rm -rf /Applications/Emacs.app && mv "$(brew --prefix emacs)/Emacs.app" /Applications</s>

EDIT: Scrap this, it doesn't work for emacs --with-cocoa due to #3330 (comment).

[ilovezfs]

You should be aware that another one of the Laws of Robotics is that we're trying to kill off as many caveats as possible, but that could arguably be treated as one of the "valid" uses. I think that leads naturally to being replaced with an automated version of the same thing, but that was already proposed and rejected in https://github.com/Homebrew/brew-evolution/pull/3, so I'm really not sure where that leaves us logically other than launching apps from the Cellar, which I'm fairly sure no one will be OK with.

[zmwangx]

The resolution of Homebrew/brew-evolution#3 was

I think we have some sort of agreement here that we will not implement this proposal but instead start to gradually deprecate linkapps (by moving app bundles out of HB), right?

(Parenthesized part by me.)

And out of all these /^\w+ migrated to cask$/ PRs, only the Emacs thread has (rightfully) generated this much attention, so I think it's fair to not replace with an automated version (hard to do satisfactorily anyway) and leave a caveat for this special case.

[ilovezfs]

@zmwangx I think for the sake of fairness we might have to include macvim too :D

[DomT4]

I suspect it's quite likely that if we bar .apps completely, regardless of mandatory/recommended/optional status, we will end up launching GUI apps out of the Cellar in much the same way we already have done previously.

Before it was CLI only executing a vanilla fontforge launched the GUI, rather than using the .app which was broken (Not due to Homebrew in particular, I add). With wireshark before the latest release you used to only be able to access the GUI by running for example a vanilla wireshark; there's an .app now but that method of launching is still supported. Same with emacs --with-cocoa - Vanilla execution launches GUI.

Ultimately if we shoot down .apps 100% with no exceptions or optional inclusion, that's where we're heading again unless we completely bar GUI in Homebrew, in which case a big chunk of the GTK/GTK+3/Qt/Qt5 dependency tree is off to die.

[zmwangx]

@ilovezfs Well, vim is going nowhere, so I don't think the Church of Emacs owe the Cult of vi anything here... But free feel to appeal #3337, I'm always happy to see people's wished granted, even if people refer to vi users 😃

Same with emacs --with-cocoa - Vanilla execution launches GUI.

Ah, I forgot that. Yes, that's quite annoying.

[ilovezfs]

@zmwangx The reason that it's probably fine that MacVim has been moved is that the upstream build has nearly every option enabled. Is there no analogue for emacs that isn't awful?

[zmwangx]

Is there no analogue for emacs that isn't awful?

Not that I know of. emacsforosx.com (built from https://github.com/caldwell/build-emacs) is sort of semi-official, but it doesn't come close to having every option enabled (caldwell/build-emacs#1 might be the reason; see also caldwell/build-emacs#25 and caldwell/build-emacs#37). I don't know any other trusted binary distribution.

There are probably Emacs experts around here who can tell you more.

[zmwangx]

It can be restricted to system volume, or any target volume, or to a user directory.

I know it can be any target volume (with caveats of course), but I didn't know -target can be a user directory. man 8 installer doesn't seem to say that, and I just tried that with MacTeX which resulted in an error:

$ installer -verbose -package /Volumes/ext/software/misc/mactex/mactex-20160603.pkg -target /tmp
installer: Error trying to locate volume at /tmp

In practice, hard coded /Applications/foo.app is usually fine.

But you just violated the "relocatable" principle 😉 And emacsforosx.com is supposed to be a "To install, drag this icon (to anywhere)..." app.

[ilovezfs]

Using the user directory has to specifically be enabled in the plist file embedded in the pkg. You can't just do it with anything.

As for relocatibility, I believe that can work with upgrades and delta upgrades if properly configured with rpath, etc. and relocatibility is toggled on in the pkg plist. I've just not played around with that feature personally.

I don't even think it would be totally crazy to hard code the paths for an app bundle that only works if located in /Applications or go a step further and have hard-coded internal paths pointing into /usr/local/Cellar assuming it worked well.

From an ease of upgrade perspective I think being able to use Homebrew bottles including non-relocatable ones would be nice. It would be interesting to know how many of the full set of optional and recommended formula deps for emacs have relocatable bottles vs non-relocatable bottles.

[DomT4]

In practice, hard coded /Applications/foo.app is usually fine.

I believe from macOS 10.12 applications aren't actually going to live in /Applications, even though they'll still, er, exist in /Applications. I think Apple is randomising the path or something, so it's not entirely predictable. I was only half paying attention when this was discussed on the WWDC stream.

[zmwangx]

Using the user directory has to specifically be enabled in the plist file embedded in the pkg. You can't just do it with anything.

I see.

I think Apple is randomising the path or something, so it's not entirely predictable. I was only half paying attention when this was discussed on the WWDC stream.

Which session is it, security? (Now that you mention it, I realized I haven't watched the security session yet.)

[DomT4]

Yeah, "Gatekeeper Path Randomization". From 30:22 in this video. There's a blog post here.

[DomT4]

The video possibly raises more questions than it answers about this security feature (true to form from Apple) but "If the user explicitly moves the single app by itself, possibly to applications, this mechanism will be turned off" is the big line probably interesting to us.

I hope by that they mean there doesn't have to be user involvement in physically moving the .app & programmatic moving of .apps isn't going to suddenly start being problematic 😕. Signed disk images, MAS apps & signed Apple installer packages are exempt as well.

[zmwangx]

While this GPR is interesting and confusing, I doubt it will affect any of our command line workflows. Gatekeeper relies on com.apple.quarantine and optionally com.apple.metadata:kMDItemWhereFroms to determine if an app is downloaded, unzipped, etc. curl, tar, unzip etc. don't set those xattrs, so there's no way Gatekeeper could tell that the app was downloaded or built from source or whatever.

As an example, I just tried to unzip AppCleaner-3.3.zip. When I unzipped it with The Unarchiver (GUI app) and tried to launch the app, I got a prompt "'AppCleaner.app' is an application created by The Unarchiver. Are you sure you want to open it?" When I unzip on the command line instead, the app just launched with no Gatekeeper BS.

And just for fun, I also tarred up /usr/local/opt/emacs/Emacs.app and untarred with The Unarchiver. This time it couldn't be opened because it wasn't signed... Interestingly enough, Archive Utility doesn't set com.apple.quarantine so the resulting app wasn't subject to Gatekeeper, and it opened up just fine.

EDIT. I'll add that the experiments were done on 10.11.6.

[DomT4]

Potentially worth tying into this discussion is the Cask discussion on setting Gatekeeper on downloads to close a potential security hole: Homebrew/homebrew-cask#22388

EDIT. I'll add that the experiments were done on 10.11.6.

I've got a 10.12 VM. I'll try duplicating your experiments later there, but I agree with your summary that if nothing changes with us or Cask it should be alright, at least for now; Apple could well expand or pull back on the changes before 10.12 goes stable.

[zmwangx]

I find manually enabling Gatekeeper (which from my experience isn't so helpful to begin with) rather paranoid, but I'll read the Cask discussion later to see where people are coming from.

I removed my 10.12 VM yesterday to save some ~30G of space so I can't test anything now...

---

Okay, I think we're way off-topic now so I'll stop right here.

[DomT4]

I sympathise with the Cask team, although they haven't set out their argument as far as I can see, in that users are likely to invest a certain amount of trust in them & may presume they offer no less protection* than Apple, and consequently may adopt less cautious behaviour assuming that protection is there.

It's not entirely fair, but I wouldn't be surprised if that's how they've been left feeling at times. The weight of knowing so many people trust you isn't something that is particularly easy to carry.

*Protection is subjective.

[ilovezfs]

Let's just collectively agree that whenever a Homebrew user uses Cask in a way that requires sudo that he or she is a Cask user, not a Homebrew user, with respect to that action and its consequences, regardless of whether brew was part of the original command-line invocation or not.

[CamJN]

Since no one has mentioned it, I'd like to point out that --with-ns actually enables better colour support when run in the terminal (ie run emacs with the -nw flag), there was (might still be) a patch that you only get with that flag that prevents emacs hanging in some cases, and in general it is used as a bit of a "mac stuff here" flag in addition to "build a mac gui".

Believe me, I wouldn't build the gui if it wasn't worth it, I have to go to great lengths to make sure I don't accidentally launch the gui by mistake. But the improvements that come with it aren't something I'm willing to give up.

Also to those whinging about quitting Emacs: Ctrl-x Ctrl-c is way easier than hacking through my power cable with an axe and lighting my computer on fire which is I believe the official way to quit vim 😛.

[ilovezfs]

--with-ns actually enables better colour support when run in the terminal

That alone sounds like a sufficient reason to make it the default.

[ilovezfs]

If GUI should not be default, it sounds like we should make the cocoa option default enabled, but have an env script wrapper that sets -nw.

[zmwangx]

@ilovezfs What's -tw? You mean -nw? There's a problem with this approach: -nw is --no-window-system, and there's no --no-no-window-system option.

[ilovezfs]

@ilovezfs What's -tw? You mean -nw?

Yes, -nw, sorry.

There's a problem with this approach: -nw is --no-window-system, and there's no --no-no-window-system option.

We could teach the wrapper script to accept --window-system and --no-no-window-system, right? But probably what would be more straightforward is to have a separate script for the exec #{prefix}/Emacs.app/Contents/MacOS/Emacs "$@" behavior.

[zmwangx]

We could teach the wrapper script to accept --window-system and --no-no-window-system, right? But probably what would be more straightforward is to have a separate script for the exec #{prefix}/Emacs.app/Contents/MacOS/Emacs "$@" behavior.

Both sound wrong to me, because I don't think we are in the position to offer additional binaries or otherwise non-existent options. Also, the situation is a tad more complicated for emacsclient.

Overall I don't think defaulting --with-cocoa is a good idea.

[ilovezfs]

Overall I don't think defaulting --with-cocoa is a good idea.

I'll leave that between you and @CamJN, then ;)

[MikeMcQuaid]

If we leave GUIs in here: we're defaulting to non-GUI options where possible.

[ilovezfs]

It seems like this is one where we're going to end up with both the formula and the cask in perpetuity, which may be fine, I guess.

[DomT4]

I think not defaulting to a GUI is sane, personally. I think we should keep the GUI option for emacs, but I think keeping it as an option is a reasonable compromise that everyone will be a little annoyed by but nobody will be completely outraged by.

Also to those whinging about quitting Emacs: Ctrl-x Ctrl-c

Oh, how intuitive 😈 😉

[ilovezfs]

@DomT4 do you agree that the Cask should continue to exist as well in this case?

[zmwangx]

do you agree that the Cask should continue to exist as well in this case?

Cask does provide a better macOS app experience for people who don't need the optional deps (ignoring the upgrade issue, which isn't much of a problem for stable users since the stable channel is seldom updated, just like how Apple updates Macs these days).

[DomT4]

@DomT4 do you agree that the Cask should continue to exist as well in this case?

I don't have major beef with the Cask continuing to live. I think it & our --with-cocoa option basically do the same thing in slightly different ways, but both are just as valid. I don't expect that to be the case with most things, but it seems to be so here.

[MikeMcQuaid]

Passing on this for now as per discussion. Thanks again for opening @AnastasiaSulyagina. Have opened a PR with various tweaks discussed here in #3531.

[julienchastang]

If anyone is missing the X11 formula, here it is.