Item — HN Reader

From the post: "Homebrew helps you compile different kinds of software on your mac, making it feel almost as easy as apt-get'ing a package on e.g. ubuntu." (emphasis added)

This is something I've noticed from using both OSX and Linux for the past few years — unless software is available as a drop-and-install package, it's universally _easier_ to install in Linux* than it is in OSX. Given the market for OSX and the amount of development that happens on it, I'm surprised the situation isn't better (for OSX), but perhaps that just speaks to the work people have done on package managers for the various linux distributions.

* - Holds true, in my experience, for Ubuntu and Arch. Likely the same for other distros..

2 comments

Yes and no. Having done professional and personal development for OS X and two linux distributions (Fedora / Gentoo) it is most definately easier on Linux if you want to just hack together some software for your own use. As soon as you want to distribute that software however, the advantage often disappears - you can't use the package manager version of a lib because you need a feature in a later version, or because you need a different option activated during compile. Or you have a patch for said library that was refused upstream.

If anything like this happens in a dependency of your module, you're probably going to have to recompile all of the downstream dependencies by hand, or risk breaking your development system.

To avoid all of this you end up compiling static versions of the libs from your dependencies, and linking them statically to your module. This is particularly true if you don't want to be at the mercy of upgrades to those dependencies in your distribution that break your code.

Looking at things from the other side, there have been various package managers for OS X that give some of the ease-of-development available thanks to yum or apt-get. At the moment homebrew seems to be getting quite a bit of traction, and has addressed many of the pain points that predecessors such as MacPorts and fink have had, making OS X decidely more linux-like when you're writing the software without plans for distribution.

I'm a long-time macports user, and brew just blew me away with how much less work it made me do! (even just in terms of other source builds finding libraries by themselves - a real boon.)

I'd really like to use both macports and homebrew, and switch between them as necessary, but I don't know a good way of doing this. I know homebrew is relatively well-behaved and doesn't really put stuff outside /usr/local, but other things install into /usr/local too so I can't just remove that from my PATH when I want to use macports.

If anyone knows a reliable and simple way to do this I'd be very grateful.

I'm not sure to what extent this works with brew, but you could try using virtualenv to manage different environments?

I've never had to deal with multiple configurations on the same mac (my solution, off hand, would be to use debian VMs, possibly through SSH rather than a desktop GUI if I needed >1 at a time.)

Yeah, I'm thinking about going down the VM route with Ubuntu Server inside Parallels. Seems a bit of a waste of computing resources though.

virtualbox is free! And fine for the purposes of running scientific software.

EDIT: and in terms of resource usage, RAM is cheaper than headaches.

it's universally _easier_ to install in Linux than it is in OSX*

Unless the package is not in the repositories or you want to have an instance with some different flags. One of the really nice things of Homebrew is that besides being a package manager, it is a great /usr/local manager.

For instance, installing something that is not in Homebrew is as simple as setting the prefix to /usr/local/Cellar/whatever/version and then running brew link whatever and it puts symbolic links in /usr/local. Want to make it 'invisible'? Just do a brew unlink whatever

It's also much easier to maintain your own Homebrew repos (taps) than e.g. maintaining an Ubuntu PPA.

Or it simply has a name you don't expect. A lot of the problems I had in Linux, before I got used to it, was simply not knowing what I needed to install.

I'm used to being able to do, 'brew install foo' and not needing to worry if I needed libfoo, libfoo-dev, libfoo3-dev or just plain foo.

  apt-cache search foo

Done :). But I see your point. There's usually the library, the development headers plus static link library, and possibly some command line tools.

And usually the headers aren't that big (with the notable exception of template-heavy C++), so it's much simpler installing everything.

But such splitting primarily occurs in the Debian family.