
How to Distribute Binaries for OS X Using Homebrew - tpwong
http://octavore.com/posts/2016/02/15/distributing-go-apps-os-x
======
paulirish
> At least on OS X, things are a little easier with Homebrew.

Absolutely. I adore Homebrew and it's ecosystem. Cask, in particular, is quite
satisfying; gotta love installing a swath of neccessary fonts from the
terminal. And, fwiw, the project is about to be on Homebrew, with no tap
required:
[https://github.com/Homebrew/homebrew/pull/49040](https://github.com/Homebrew/homebrew/pull/49040)
Though getting it up was not quite as pain-free than our initial publishes to
NPM.

The thing is: Homebrew solves the problem for just a portion of your audience.
In diff-so-fancy's case, we've supported Linux and Windows from the get-go,
the only hard part is getting it installed. NPM solves that problem really
well, and I can't imagine any other installation technique being our
recommendation for Windows/Linux going forward.

~~~
rubiquity
This only makes sense if you believe all Homebrew packages are written in
JavaScript... which they aren't. Also I've been using Homebrew for about 4x as
long as NPM and I have about 1/10th of the issues, so I'll just stick to the
package manager that works.

~~~
maxthegeek1
You can use npm to distribute binaries.

~~~
EvanPlaice
That doesn't mean it's a good idea to.

NPM does a great job of distribiting development dependencies and Node.js
applications.

It's not really intended for non-js binary builds and platform-specific
dependencies.

You can always use NPM to install directly from specific repo release but
you'll still have to have to include a native compile-to-platform step
somewhere.

------
stepanhruda
You don't even need to maintain a separate custom tap repo. Keep the formula
in the same repo in a Formula directory, and include the repo URL when tapping
(gets rid of the homebrew- restriction)

The brew command for users would be:

brew tap octavore/delta
[https://github.com/octavore/delta.git](https://github.com/octavore/delta.git)

brew install delta

\---

Example above of course doesn't currently work because the formula is not
there

(I successfully use it in my repo: [https://github.com/stepanhruda/ios-
simulator-app-installer](https://github.com/stepanhruda/ios-simulator-app-
installer))

~~~
guptaneil
I find the method described in the post to be cleaner UX. Sure, it requires a
little extra work on your part to setup, but running a single `brew install
octavore/tools/delta` is much nicer and easier to remember than

brew tap octavore/delta
[https://github.com/octavore/delta.git](https://github.com/octavore/delta.git)
brew install delta

~~~
stepanhruda
You're definitely right, just wanted to provide an alternative I found useful.
95% of the time I copy & paste brew commands for custom taps from the repo, I
wouldn't remember the 3-part path anyway.

This is probably asking for a PR to hombrew, the ideal command would be

brew install delta
[https://github.com/octavore/delta.git](https://github.com/octavore/delta.git)

------
OJFord

        > when a post on better diffs showed up on Hacker News
        > last week ... people below are asking why a bash script
        > (that depends on a perl script) is being recommended to
        > install via NPM? [cont. about using Homebrew]
    

This post is useful in general, but just to circle back on its motivation, for
anyone wanting a non-npm (brew) install of the aforementioned diff tool (diff-
so-fancy, not made by me) - I've a PR pending merge - Homebrew/homebrew#49040
[0].

In the mean time, you can tap it:

    
    
        % brew tap OJFord/formulae
        % brew install diff-so-fancy
    
    

[0]([https://github.com/Homebrew/homebrew/pull/49040](https://github.com/Homebrew/homebrew/pull/49040))

------
vayan
>Cross-platform app distribution is a hard problem! [...] At least on OS X,
things are a little easier with Homebrew

well.. yeah.. Every OS has an easy way to distribute binaries, the hard part
is having something that work on each of them.

~~~
m_mueller
Every OS ... except Windows?

~~~
provemewrong
Didn't Windows 10 get PackageManagement FKA OneGet? I mean I haven't upgraded
because of privacy, but at least it exists.

~~~
m_mueller
Interesting, TIL. I wonder how complete it is. E.g. how much work until you
have python and pip? gcc? An SMTP Server? A web server?

------
AceJohnny2
I've been forcefully switched to OS X recently because work, and overall it's
been pretty great (I view it as a well-integrated UI over FreeBSD). A couple
of things drive me nuts though:

* (the window manager sucks, but that's not the topic. I had to get it out)

* it needs a good package manager

For us ol' bearded folk (at least spiritually), OS X comes with a slew of unix
tools we love. It already includes both vim AND emacs! However, these tools
are hopelessly outdated: Despite OS X 10.11 "El Capitan" coming out last fall,
Vim is still 7.3 (that's from August 2010. 2010!), and Emacs 22 (2007. That's
right.)

So some enterprising folk come to the rescue: Fink, Homebrew, Macports...

Homebrew installs over /usr, so come the next OS update, all that gets
squashed. Macports installs into /opt/local, but somehow doesn't survive an OS
update. Also, when I tried installing SciPy it went and recompiled GCC4 from
source. Guys, the 90s called, and it's been shown that recompiling from source
for each user isn't worth the effort.

Apple gave MacPorts some support in the form of equipment, so there's some
hints of their preferred method. But the core WTF is this: why doesn't OSX
integrate a package manager for its unixy side?

~~~
ksherlock
I used macports through two or three upgrades before switching to home-brew
last year. Switching was one of the best decisions I ever made. In terms of
MacOS package managers -- in the grand scheme of things it's not really a big
deal. First world problems, right?

MacPorts is very, umm, opinionated. And doesn't seem to trust anything outside
of itself. And has some weird opinions, too.

Example: For some reason, svn is a dependency for nmap. Forgot those gravity
waves, the next nobel prize belongs to whoever can figure out why a network
scanner depends on an obsolete version control system. So macports installs a
shiny new version of svn. Which doesn't play nice with the svn that Xcode
uses. Overtime I run (macport) svn from the command line it tells me to
upgrade my repository, which breaks the Xcode svn.

~~~
tjl
This kind of stuff is why I abandoned MacPorts. In many cases, I can get by
with the system software and I don't need MacPorts to install a duplicate of
something. I found that it was taking up a lot of space on my drive. Given
that my main drives are relatively small SSDs, I appreciate that Homebrew
doesn't require that I switch to a different version of a system tool in many
cases.

The worst offender for MacPorts was TeX. I had an official install the latest
version from TeX Live and MacPorts wanted to install a second version of TeX.
I think they fixed it so you can use a TeX Live version, but it was definitely
an issue.

------
mschuster91
Homebrew sucks on multi-user systems (especially if the Mac in question has
previously been single-user) or after the Mac changes its owner/becomes a
shared one (company laptop).

Macports handles this usecase far, far better. Give your users sudo rights and
be done. Only thing it desperately lacks is allowing third-party additional
repositories like Debian's apt does.

~~~
matt_wulfeck
It always bugs me when people don't wipe laptops before handing them off.

~~~
mschuster91
In a company environment with shared machines?

------
rdl
I still use macports; what's the current state of opinion of homebrew vs. fink
vs. macports?

~~~
knodi123
the current _trend_ , based on what I've seen open-source projects using,
seems to be strongly towards homebrew. Not sure if I've seen a project
recommending install via fink in quite a few years.

------
shiftoutbox
Step 1 use pkgsrc . Not joyent's pkgsrc , but real pkgsrc . Step 2 see step 1.

~~~
shiftoutbox
Step 0 don't use homebrew .

------
hk__2
You don’t even need to check the SHA256 by hand, just use `brew create
<tarball URL>`. It’ll create a formula with a sensible name, fetch its URL,
populate the SHA256, and open the file in your editor. However note it’ll
create it in the core formula directory instead of your tap; you’ll need to
move it yourself.

------
zwetan
>Cross-platform app distribution is a hard problem!

indeed, but couple of things

specific to Mac OS X: there are homebrew, macports, fink and probably more

distributing with homebrew to someone who already going with macports is
problematic for example as it is advised to not have both installed.

One alternative is to distribute a pkg and so use PackageMaker to build one.

A pkg has the pros to be native to Apple, but the cons to not work for other
systems like Windows and Linux.

So here another alternative: Debian packages (deb).

Wether with macports, homebrew or fink you can install the command line
utility dpkg, and using dpkg-deb you can build deb supporting the darwin-amd64
arch.

For Windows, you can use the utility wpkg,
[http://windowspackager.org/](http://windowspackager.org/) and with it you can
build deb packages for win32 and win64 architectures.

Ultimately if you distribute command-line tools (not GUI app), you can use deb
packages for Windows, Mac OS X and Linux Debian (Ubuntu etc.)

Here an example (one of my tools that I need to distrib/install on servers):
[https://github.com/Corsaair/as3shebang/releases/tag/1.0.0](https://github.com/Corsaair/as3shebang/releases/tag/1.0.0)

Debian packages for everyone :)

Linux and Mac OS X install: dpkg -i as3shebang_1.0.0_amd64.deb

Windows install: wpkg -i as3shebang_1.0.0_win64.deb

You can see the build scripts at the root of the repo, they are pretty
similar.

Also, once you have deb packages you can also convert them to rpm and other
nix-like packages usinga tool like alien, see
[https://en.wikipedia.org/wiki/Alien_(software)](https://en.wikipedia.org/wiki/Alien_\(software\)).

------
chris_st
I guess you have to do this to avoid the name clash with Tigris's delta[0],
which is the default if you do `brew install delta`? I'm not sure this is the
best solution.

[0] [http://delta.tigris.org](http://delta.tigris.org)

------
ksherlock
I stumbled across this idea a few weeks ago to install some build software on
an os x travis ci build machine (using OS X is the easiest way for travis ci
to use a C++ compiler that isn't obsolete).

Anyhow, it's nice and simple approach that works.

------
guptaneil
This is awesome. I was _just_ looking a few days ago for a good tutorial on
how to distribute some bash scripts via homebrew and could not find a great
resource. Thanks for the writeup.

------
0942v8653
Rate limit exceeded. [http://archive.is/Zp8IQ](http://archive.is/Zp8IQ) works.

~~~
tpwong
Whoops, thanks for the heads up! Should be fixed now.

------
ricardobeat
This is still quite a bit more work than publishing to npm:

1\. Jump to separate repository

2\. Create a .tar.gz with sensitive filename

3\. "upload somewhere"

4\. Manually update formula, sha, version

4\. Push

Versus:

1\. npm bump && npm publish

I ended up automating the formula updating after getting tired of doing that
every other day, for a private tap.

~~~
tpwong
I feel your pain, part of the motivation for writing this was that yesterday I
wanted to set up a new project, and realized I'd forgotten half the steps.
Been thinking that something like [https://github.com/aktau/github-
release](https://github.com/aktau/github-release) could be helpful for
automating the release process, or maybe adding it as a step in a CI workflow.

------
Isn0gud
Its a bit off topic but is there a good alternative for windows? chocolatey
doesn't seem to be a good solution.

~~~
josteink
Scoop? [http://scoop.sh/](http://scoop.sh/)

------
mongosucks
Interesting

------
alviria
I find OS X's package/dependency management system to be as cobbled together
as Windows'.

Linux got it right:
[https://en.wikipedia.org/wiki/Package_manager](https://en.wikipedia.org/wiki/Package_manager)

It drives me crazy that Apple removed one the most amazing features of *nix
systems: a unified software repository. Brew/brew cask doesn't come close to
AUR.

~~~
masklinn
> It drives me crazy that Apple removed one the most amazing features of *nix
> systems: a unified software repository.

It's not a feature of unices, it's a feature of _Linux_ (Ian Murdoch called it
"the single biggest advancement Linux has brought to the industry"[0]).

The vast majority of unices never had a "unified software repository", and
BSDs (probably the least indirect ancestor of OSX) have port trees, which at
the time OSX was born (ignoring the NeXTSTEP ancestry which predates "modern"
BSDs and builds directly from 4.3BSD) were a very different beast and not
something suitable proprietary unices (because Apple wasn't going to give the
OSX commit bit to randos).

And hell, both apt and rpm were busy _being born_, the premier package
managers at the time were raw dpkg and pms(1). And pkgtool[1] I guess?

[0] [http://ianmurdock.com/solaris/how-package-management-
changed...](http://ianmurdock.com/solaris/how-package-management-changed-
everything/)

[1]
[http://www.slackware.com/config/packages.php](http://www.slackware.com/config/packages.php)

~~~
alviria
The problem I'm seeing is that what OS X has isn't a unified system, and what
Apple promotes isn't want developers want to/can use. So you see time and
effort going into tools like this that only last a few years. It results in
more fracturing in the end.

In this popular diagram,
[https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his...](https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-
simple.svg), NeXTSTEP was originally forked in 1988, before Linux really had
package management put together. Darwin is from 2001.

Is 14 years not enough time to establish a proprietor supported unified
package management system?

My expectations may just be set too high.

~~~
jd3
I think you are underestimating Apple's apathy when it comes to doing anything
of real interest anymore. We don't even get Darwin .iso releases or changelogs
anymore. [0] We are left in an arguably worse state of affairs. It's not just
sad; it's boring.

[0]:
[https://opensource.apple.com/static/iso/](https://opensource.apple.com/static/iso/)

