Show HN: Homebrew-emacs – Install Emacs Packages via Homebrew | Hacker News Reader

Show HN: Homebrew-emacs – Install Emacs Packages via Homebrew

ejd791.wordpress.com

11 pointsedavis9 comments

I'm a big Emacs user -- have been since 1991 -- and Homebrew-emacs (the subject of this Show HN) seems like a very good idea to me.

Homebrew has become the most popular and most important package manager on OS X. More people use Homebrew (and consequently have invested time learning how to use, configure and modify Homebrew) than use Emacs. Although I know that the following opinion is subjective, I am tempted to assert that Homebrew is more important than Emacs -- not only more important than any package manager implemented in Emacs Lisp, but also more important than any Emacs package or any file or coherent collection of files of Emacs Lisp code.

I have installed a few packages into my emacs using package.el (which comes with Emacs these days). I don't like package.el very much. All I can remember (in the 20 minutes or so since I started reading this story on HN) about package.el without looking it up is that M-x list-packages is often useful as a first move in trying to get package.el to do what I want. Most software distributed with Emacs by the FSF is well implemented, but a lot of it is also poorly designed.

Don't get me wrong -- I'm not going to stop being heavy Emacs user any time in the forseeable future. It's just that I've learned long ago that it is a waste of my time to learn or master all of the functionality distributed as part of Emacs.

One more thing. At this moment, I have 32 Homebrew packages installed. My memory tells me that I have 2 or 3 packages installed in my Emacs via package.el, but my memory is unreliable, and there is no way in hell I'm going to invest the tedious time and mental energy required to figure out how to get Emacs to tell me how many packages I have installed at this moment. In contrast, my determining that I have 32 Homebrew packages installed required almost no thought at all. Right away I knew how to get the information, and the whole process took me at most 5 or 10 seconds.

It involved the command line "brew leaves". I dont have "brew leaves" memorized, but I knew that somewhere in my .emacs.d is a call-process call to /usr/local/bin/brew that essentially lists all the packages I have installed, so searching my .emacs.d for the string "brew" got me the information I needed (namely, the Homebrew command is "leaves") in a matter of seconds.

Thanks for the feedback. Really appreciate it.

Your comment hits on a lot of the points that motivated me to create homebrew-emacs in the first place.

For me, Homebrew is a pleasure to use. It's stable, robust, sensible, and has a great community around it.

ELPA, on the other hand, never seemed to have the same polish. Maybe with enough time and energy I could have configured ELPA to my liking. But that prospect never appealed to me when I have a perfectly good package manager I already use for everything else just sitting there.

Yes, the last time I installed OS X, I didn't even bother to install MacPorts (or any other package manager).

The only package manager I currently use is Homebrew. If I ever switch from OS X to Linux, I will almost certainly need to switch package managers at the same, which is no big deal: I've used RPM, dpkg, apt, pacman and Arch Build System in the past, and I am extremely confident that I could bend them to my will in the future.

Again, I want to stress that I think certain parts of Emacs are great. package.el on the other hand did not impress me enough for me to want to spend even one more hour learning about it. I would guess I have something between 5 and 50 hours invested in learning about package managers written in Emacs Lisp up to today. (All of those hours were spent learning about package.el or whatever the correct name of it is.)

I like the idea behind homebrew, but the implementation, particularly its desire to own /usr/local, leaves a bit to be desired.

I already use /usr/local for packages I install by hand. Homebrew doesn't play nicely with others. If it could be configured to use /opt/homebrew, for example, I'd give it another try.

I went surfing around the Homebrew docs to see if there was an option, or at least consideration, for your objective. Turns out it's in the FAQ (as well it should be):

https://github.com/Homebrew/homebrew/wiki/FAQ#why-does-homeb...

Their claim is that a lot of software is poorly written and does not tolerate non-standard include or lib paths aligns with my own experiences.

Also, FWIW, they allege a few questions further down in the same FAQ that they do not own /usr/local and thus you can put your own items there willy-nilly; just be cautious about rebuilding libs that are shipped by Apple and sticking them in /usr/local.

But Emacs ships with a built-in package manager, there is no setup, you literally just say "M-x list-packages".

I wouldn't go so far as to say "no setup."

I just tested it and what if I want to install magit? As it isn't included in the default repo, I'll have to add MELPA. At this point is there much difference between adding MELPA to package-archives and `$ brew tap edavis/emacs`?

And, for me, I already use Homebrew for just about everything else. Using ELPA to manage Emacs and Homebrew to manage everything else is doable — but just not what I'm looking for.

I'd love for one day to be able to run `$ brew upgrade` and have python, redis, org-mode, and magit all upgraded in one shot. The project isn't there yet but I'd love to see it get there.

My initial reaction is that this doesn't seem like a good idea. Emacs already has a package manager which works across platforms. If you use homebrew to configure your emacs instance on OSX how are you going to provision an equivalent emacs instance on e.g. a linux VM?

True, but that isn't a scenario I have to deal with. My development machines are both OSX. If I need an emacs editor on a linux box, I fire up mg. I just haven't needed to provision emacs on a non-OSX machine for years now.

If cross-platform package support is a requirement, then this project is definitely not sufficient.

But as every development tool I use is already managed by Homebrew, this is the more natural extension for me — not ELPA.

Reply on news.ycombinator.com