Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

emacs: cleanup formula. #3531

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
8 participants
@MikeMcQuaid
Copy link
Member

commented Aug 2, 2016

  • 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?
  • Have you built your formula locally prior to submission with brew install <formula> (where <formula> is the name of the formula you're submitting)?
  • Does your submission pass brew audit --strict --online <formula> (after doing brew install <formula>)?

  • Remove X11 support
  • Share configure/make/make install section
  • Remove unneeded fails_with :llvm
  • Remove obvious caveats

Based on discussion in #3330.

@MikeMcQuaid MikeMcQuaid referenced this pull request Aug 2, 2016

Closed

emacs migrated to cask #3330

2 of 2 tasks complete
@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

@MikeMcQuaid did you want to have a caveat "recommending" the user consider switching to the cask whenever it's a --with-cocoa build?

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Aug 2, 2016

@ilovezfs I think we can leave as-is for now but: worth considering later. I'm still consider us moving this and MacVim to a Cask but: not right now.

@zmwangx

View changes

Formula/emacs.rb Outdated
system "make", "install"
else
args << "--without-x" << "--without-ns"
end

This comment has been minimized.

Copy link
@zmwangx

zmwangx Aug 2, 2016

Member

Just curious, why --without-x only when building without Cocoa support? I know that's the original logic, but I wonder if it's appropriate.

This comment has been minimized.

Copy link
@MikeMcQuaid

MikeMcQuaid Aug 2, 2016

Author Member

Good point.

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

Yeah it would be nice to see the analytics numbers on the use of the --with-cocoa option drop off a cliff.

Regarding MacVim, upstream's version is very complete but I think people may want to continue being able to link against their local Python, etc. That said, it's worth noting that upstream has its own version of the formula: https://github.com/macvim-dev/homebrew-macvim/blob/master/macvim.rb

@zmwangx

This comment has been minimized.

Copy link
Member

commented Aug 2, 2016

#1616 (about emacs --with-x11) can be closed when this one is merged. Not sure the OP will be thrilled, though.

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

ilovezfs smells an xemacs.rb coming for homebrew-x11

@zmwangx

This comment has been minimized.

Copy link
Member

commented Aug 2, 2016

ilovezfs smells an xemacs.rb coming for homebrew-x11

XEmacs is already a thing, and it's not GNU the Generally Not Used Emacs.

emacs: cleanup formula.
- Remove X11 support
- Share `configure`/`make`/`make install` section
- Remove unneeded `fails_with :llvm`
- Remove obvious caveats
@DomT4

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

ilovezfs smells an xemacs.rb coming for homebrew-x11

Nope. Nope. Nope. Nope. Nope.

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

@DomT4 it's ok to come out of the fetal position now :trollface:

@julienchastang

This comment has been minimized.

Copy link

commented Oct 6, 2016

It took me a while to find out why X11 emacs can no longer be installed via homebrew, but I finally made it here. As I understand the situation, the X11 option was not broken. It was a non-default option and therefore not hurting anyone. I am hoping to see this option brought back to life. If it ain't broke, don't fix it.

Edit: Here is X11 formula, if anyone wants it.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2016

I am hoping to see this option brought back to life. If it ain't broke, don't fix it.

Edit: Here is X11 formula, if anyone wants it.

Maintaining it yourself is the best fix. We're slowly removing X11 support from homebrew/core.

@syl20bnr

This comment has been minimized.

Copy link

commented Oct 8, 2016

It took me a while to find out why X11 emacs can no longer be installed via homebrew

I'm in the same boat.

Why on earth have you removed the support for X11 ?? XQuartz is still a thing on macOS.

Here is X11 formula, if anyone wants it.

Thank you sir :-)

@syl20bnr

This comment has been minimized.

Copy link

commented Oct 8, 2016

We're slowly removing X11 support from homebrew/core.

Can we have more information about this move ?

It is very unpleasant to make such changes with no information whatsoever, combine this with macOS update and you have a wonderful recipe to waste time for a lot of people...

Doing a brew info emacs was the last thing that came to my mind, I had to read the output several times to believe my eyes.

@dunn

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2016

Can we have more information about this move?

We've long banned formulae with hard X11 dependencies from the core tap; X11 on macOS is a pretty poor user experience so we've been giving preference to software that provides a native graphical interface.

I agree the change was easy to overlook, but we don't really have a mechanism for publicizing changes to formulae options. One solution might be to throw an error if non-existent options are used when installing or upgrading, but nobody has implemented that yet.

@syl20bnr

This comment has been minimized.

Copy link

commented Oct 8, 2016

Thank you for the answer.

Emacs with X support works flawlessly with XQuartz (coupled with a good
tiling window manager like i3).
Maybe Emacs should be an exception because X11 is an optional dependency.

Removing X11 because the formula is in homebrew-core and putting Emacs
formula in homebrew-x11 are both unsatisfying solutions. The first one
remove support for a perfectly valid facultative option and the second one
does not fit the purpose of the repository.

Simple questions: what are the downsides of letting the support for X11 for
Emacs besides it is not tested ? Why forcing users to use cocoa if they
want a GUI ? What the point exactly ? If X11 support gets broken (and it
never broke for me in more than 3 years!) we just report it as an issue or
directly provide a fix. Is there a deep consequence for the homebrew
project to support --with-X11 for the Emacs formula ?

Le samedi 8 octobre 2016, Alex Dunn notifications@github.com a écrit :

Can we have more information about this move?

We've long banned formulae with hard X11 dependencies from the core tap;
X11 on macOS is a pretty poor user experience so we've been giving
preference to software that provides a native graphical interface.

I agree the change easy to overlook, but we don't really have a mechanism
for publicizing changes to formulae options. One solution might be to throw
an error if non-existent options are used when installing or upgrading, but
nobody has implemented that yet.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3531 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABL5kYMIky56t_wc1xn416w-szvXrpVEks5qx-uKgaJpZM4JajHH
.

-syl20bnr-

@dunn

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2016

There's a lot of discussion here: #3330

Different maintainers have different opinions. For my part I supported removing X11 to simplify the formula and to encourage the native UI, but I would defer to a vocal majority who wants X11 back.

@syl20bnr

This comment has been minimized.

Copy link

commented Oct 9, 2016

Thank you for the link, interesting discussion there. We can see that Homebrew is looking for an identity or at least for some more conventions.

For my part I supported removing X11 to simplify the formula and to encourage the native UI

It does not simplify the formula so much: julienchastang@245d075
I don't expect the complexity of supporting X to grow out of hand.

Is it possible to encourage the native UI by setting it as default?

My big question is why the current Homebrew model cannot fit the Emacs recipe? It is a rather big flaw if an official option of a package built from source and supported for the targeted plaftorm cannot be "philosophically" supported by the tool although this tool can practically handle it, it is in direct contradiction with the goal of the project. Or maybe I don't understand or I lost the meaning of Homebrew.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Oct 9, 2016

Why on earth have you removed the support for X11 ?? XQuartz is still a thing on macOS.

To repeat myself from 829f0d1: because macOS doesn't ship with X11 support and Homebrew is deprecating it. Please don't post the same comment in multiple places, thanks.

We've long banned formulae with hard X11 dependencies from the core tap; X11 on macOS is a pretty poor user experience so we've been giving preference to software that provides a native graphical interface.

Yes. Furthermore, Homebrew is not well suited to installing GUIs. Homebrew Cask is a better fit for that and, now it's been integrated, we're trying to gradually move more of our GUI-using things there .

Simple questions: what are the downsides of letting the support for X11 for Emacs besides it is not tested ?

We have to support it and if it's untested and broken we're expected to fix it. As a result, it's better handled in a third-party tap (as is happening here) where it can be supported.

My big question is why the current Homebrew model cannot fit the Emacs recipe? It is a rather big flaw if an official option of a package built from source and supported for the targeted plaftorm cannot be "philosophically" supported by the tool although this tool can practically handle it, it is in direct contradiction with the goal of the project. Or maybe I don't understand or I lost the meaning of Homebrew.

Homebrew was originally not intended to be used to install GUI applications. Some have crept in anyway which I personally regret. Long-term I want to eliminate officially supporting (e.g. in the Homebrew organisation) from-source builds of GUI software where upstream provides binaries or decent macOS support of their GUI i.e. some stuff in the Gnome ecosystem may be acceptable to remain here because upstream are generally unwilling or unable to package Gnome GUI applications as macOS .app bundles.

@syl20bnr

This comment has been minimized.

Copy link

commented Oct 9, 2016

Sorry for the cross-post.

I better understand the project now, thank you. We have indeed a tap
"emacs-plus" we can support.

Of course I'm fine with your choices. This issue boils down to just have an
explicit warning when something is silently removed from a user perspective
and a brew upgrade gives a drastically different result. It's all
documentation issue in the end.

Thank you for homebrew.

Le dimanche 9 octobre 2016, Mike McQuaid notifications@github.com a écrit
:

Why on earth have you removed the support for X11 ?? XQuartz is still a
thing on macOS.

To repeat myself from 829f0d1
829f0d1:
because macOS doesn't ship with X11 support and Homebrew is deprecating it.
Please don't post the same comment in multiple places, thanks.

We've long banned formulae with hard X11 dependencies from the core tap;
X11 on macOS is a pretty poor user experience so we've been giving
preference to software that provides a native graphical interface.

Yes. Furthermore, Homebrew is not well suited to installing GUIs. Homebrew
Cask is a better fit for that and, now it's been integrated, we're trying
to gradually move more of our GUI-using things there .

Simple questions: what are the downsides of letting the support for X11
for Emacs besides it is not tested ?

We have to support it and if it's untested and broken we're expected to
fix it. As a result, it's better handled in a third-party tap (as is
happening here) where it can be supported.

My big question is why the current Homebrew model cannot fit the Emacs
recipe? It is a rather big flaw if an official option of a package built
from source and supported for the targeted plaftorm cannot be
"philosophically" supported by the tool although this tool can practically
handle it, it is in direct contradiction with the goal of the project. Or
maybe I don't understand or I lost the meaning of Homebrew.

Homebrew was originally not intended to be used to install GUI
applications. Some have crept in anyway which I personally regret.
Long-term I want to eliminate officially supporting (e.g. in the Homebrew
organisation) from-source builds of GUI software where upstream provides
binaries or decent macOS support of their GUI i.e. some stuff in the Gnome
ecosystem may be acceptable to remain here because upstream are generally
unwilling or unable to package Gnome GUI applications as macOS .app
bundles.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3531 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABL5keWPCgr59B_uM6dM9fH0UuovUb-Sks5qyMx4gaJpZM4JajHH
.

-syl20bnr-

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Oct 9, 2016

@syl20bnr No worries, thanks for the kind words and I'll take that feedback on board.

@robohack

This comment has been minimized.

Copy link

commented Apr 19, 2017

The thing that has really bothered me the most about X11 support "disappearing" from things, emacs in particular, has been that there was no announcement, and no immediate alternative, and no warning from brew upgrade, while at the same time there are still dozens of things in homebrew-core which depend on x11. (how can you possibly claim homebrew wasn't intended for so-called "GUI" applications when there were so many x11 apps included in it for so long?)

I use x11 tools almost exclusively (xquartz in full-screen mode, x11 apps run from "remote" macOS systems, etc.), and would add many more x11 apps to homebrew if possible.

Meanwhile I keep my own local patches and get aggravated every time brew update causes conflicts.

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2017

@robohack see https://github.com/Homebrew/homebrew-x11/issues/285 for prior discussions of this topic.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2017

no announcement

We don't generally make announcement of formulae changes. I realise it's not optimal but this stuff is talked about openly on the repositories' issue trackers before that.

how can you possibly claim homebrew wasn't intended for so-called "GUI" applications when there were so many x11 apps included in it for so long?

Given the age of Homebrew and the number of packages we have our aims are always going to lag behind the current reality. I can say that Homebrew wasn't intended for those applications because I've played a part in shaping that intention and am still friends with the original creator who stated that intention.

It's also worth noting that when I started working on Homebrew X11 was bundled with the OS and it no longer is.

I use x11 tools almost exclusively (xquartz in full-screen mode, x11 apps run from "remote" macOS systems, etc.), and would add many more x11 apps to homebrew if possible.

Meanwhile I keep my own local patches and get aggravated every time brew update causes conflicts.

I'd strongly suggest you add your own tools and patches by creating your own tap instead.

@robohack

This comment has been minimized.

Copy link

commented Apr 20, 2017

The whole point of Homebrew is, I think, at least as I see it, to help install things that are not bundled with the OS in the first place. It also manages the pre-requisites for those things. I don't really expect it to also install xquartz on my behalf, though that would be one way to manage the dependency of something that requires x11.

I don't think I'll be creating and maintaining a "tap" of my own -- I'll revert to manually building and installing things instead since that's actually far easier for me to do. And/or just switch to pkgsrc, which I already have to use in other contexts anyway.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2017

I don't think I'll be creating and maintaining a "tap" of my own -- I'll revert to manually building and installing things instead since that's actually far easier for me to do. And/or just switch to pkgsrc, which I already have to use in other contexts anyway.

Ok, that's up to you. That said, this is open source so if you're not willing to do something yourself you cannot expect that others will be willing to do so on your behalf.

@robohack

This comment has been minimized.

Copy link

commented Apr 20, 2017

Mike I think that's a really bad attitude to take with "your" users.

I'd be willing and able and eager to help maintain x11 support within the main "core" emacs package, but telling me to go out and build a whole part of the infrastructure and maintain it entirely on my own just so I can continue to use a "core" package with a recently unsupported option really isn't very encouraging at all.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Apr 21, 2017

I'd be willing and able and eager to help maintain x11 support within the main "core" emacs package, but telling me to go out and build a whole part of the infrastructure and maintain it entirely on my own just so I can continue to use a "core" package with a recently unsupported option really isn't very encouraging at all.

We provide a command to make running creating and running taps pretty easy: brew tap-new.

Mike I think that's a really bad attitude to take with "your" users.

I disagree. As long as this project has maintainers, it will have users. As long as we have contributors and people willing to merge those changes (i.e. maintainers) the project will keep existing. We'd glad our users find Homebrew useful but, unlike commercial software, they do not add to the project unless they are contributing pull requests or helping others to do so. I realise this may not be pleasant to hear but it's the reality of using software created and maintained by volunteers rather than a company you pay money to (or allow them to make money from your personal information).

@robohack

This comment has been minimized.

Copy link

commented Apr 21, 2017

As I said I'd be happy to help maintain an x11 option for "emacs" (and "links", and indeed to help keep other x11-only tools working in homebrew-core). I would just need to commit my existing changes to a branch, push that to a clone here on github, and submit a pull request.

However if x11 support overall is disappearing in Homebrew then that's my cue to stop using Homebrew since x11 is a major and necessary part of my working environment.

Maintaining a private tap is infinitely more work for me than the payoff of being able to continue using Homebrew. Even if I didn't have to maintain an optional tap that wouldn't necessarily be a solution unless it could override core packages, and it was part of the official Homebrew collection. Homebrew with well integrated x11 support is a nice convenient means to a desired end, but Homebrew without x11 is just an unnecessary burden for me.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2017

As I said I'd be happy to help maintain an x11 option for "emacs" (and "links", and indeed to help keep other x11-only tools working in homebrew-core). I would just need to commit my existing changes to a branch, push that to a clone here on github, and submit a pull request.

Unfortunately you cannot maintain an option in Homebrew without being a maintainer of Homebrew and watching this (high traffic) repository to help with any issues that come up with the specific formula.

However if x11 support overall is disappearing in Homebrew then that's my cue to stop using Homebrew since x11 is a major and necessary part of my working environment.
Homebrew with well integrated x11 support is a nice convenient means to a desired end, but Homebrew without x11 is just an unnecessary burden for me.

I'd say it's overall decreasing in macOS but yes: we're gradually supporting X11 less in core when possible. This may mean e.g. MacPorts is a better fit for you.

@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.