Saturday, November 10, 2012

MacPorts vs. Homebrew: My Uneducated 2¢

For the server side of my project for the Xamarin contest, I'm trying Ruby on Rails.  Never used Ruby or Rails before, but I know how slow Java webapp development is (at least with the stack of technologies I'm familiar with) and that won't cut it.  My hope is that I can copy-paste enough code from the web to get a working Rails site going quicker than I could do the same thing in Java.  This seems like a fair test of Rails, right?

Well, the Rails installer strongly encouraged me to get Homebrew and do all my prerequisite installs that way.  All I knew about Homebrew was that it existed.  I've already installed a lot of UNIX stuff via MacPorts, which seems to work fine, so I did some quick reading about the differences.  They seem to be:

  1. Installation directory: Homebrew uses usr/lib; MacPorts uses /opt/local.
  2. Dependency resolution: Homebrew uses existing system installs where possible; MacPorts always installs the latest and greatest version of your dependencies.
  3. Notions of ownership: Homebrew wants to take over /usr/lib, which is a standard UNIX install location, and set ownership for that folder to a single user to eliminate the need for sudo; MacPorts uses a nonstandard location to avoid interfering with other installs and requires sudo for installation, making installed software available to all users.
  4. OS upgrade support: Since MacPorts is in its own little world, it's not broken by system updates; since Homebrew installs to /usr/lib and depends on system libraries, it can be.
  5. Database Management: Homebrew uses git and Sqlite to track installed apps; supposedly this makes it easier to upgrade Homebrew itself.  Or something.
  6. Coolness/Prettiness Factor:  Homebrew's website is all pretty and modern and makes everything look simple and seamless.
  7. Community: Since Homebrew is written in Ruby, all the Ruby fanboys use it and all the Ruby stuff takes for granted that you're going to be using Homebrew.  I haven't yet hit any snags where Homebrew had something I needed that MacPorts didn't, but there's a lot of pressure to conform.
The best article I found comparing the two this one by Ted Wise.  I also read one slightly scary story about MacPorts.

After some reading, here were my thoughts:
  1. MacPorts sounds a lot less problematic, especially when it comes to OS upgrades.
  2. Having to download less for Homebrew sounds nice for installations at home over a not-super-fast cable internet connection.
  3. Git and Sqlite are cool, but I guess I don't really care how things are stored so long as the installs are seamless.
  4. I'm already using MacPorts, and I don't know what happens when I start mixing the systems.  I suppose everything's fine so long as I don't install the same package from both, but what about dependencies that get sucked in?  Plus, if I use both systems, I have to decide which to use for every package I install.
  5. While I don't *like* Homebrew's notions of ownership, I'm the only user of my system and I guess I don't care what it does so long as none of my existing stuff breaks and Homebrew does its thing right.  The Homebrew page assures you that's how it'll go.
  6. It would be nice to be doing things the "default" way for all the Ruby stuff.
  7. I already have stuff in /usr/lib that I've built and installed from source.  I *think* Homebrew is supposed to leave that stuff alone so long as you don't try to install the same package via Homebrew.  But I wasn't sure.
In short, I saw pros and cons for installing Homebrew but definitely didn't want to switch to it wholesale.  I decided to try things the "no-nag" way to appease the Ruby folks and install my Ruby dependencies via Homebrew.

Upon installing, Homebrew warned me that I was using MacPorts and that I should probably rename, if not delete, my MacPorts install directory.  Uh-oh.  I hoped this was only necessary if Homebrew and MacPorts installed conflicting versions of the same library, and I was going to keep my Homebrew installs to a minimum, so I proceeded.  But the Homebrew installer also encouraged me to run "brew doctor" to list all the potential problems with my system.  It complained about all the stuff in /usr/lib and then about some library from my Mono install.  And I thought, y'know, this MacPorts-all-in-its-own-world thing is starting to sound pretty nice.  So I uninstalled Homebrew using this script, installed the Ruby/Rails dependencies via MacPorts, and went on my merry way.

So.  MacPorts for me.

4 comments:

  1. Here is another fantastic tip for the fledgling developer. Andrew has laid out some nice info with his experience regarding Homebrew and Macports. This really reflected my experience as well! So for me, it was nice to see someone else duplicate that. This article has put my mind to rest over this debate. Thanks Andrew for you insight...

    ReplyDelete
  2. Hi! I'm the guy who had the slightly scary story about macports! I think the reality is that everything is "ok." Today, I needed to install GPG, and it was so easy to go:

    brew install gpg

    and minutes later, I could generate a public key. I know it's not exactly rocket surgery, and almost certainly things would have worked on macports just as easily, maybe competition will actually yield better results for the users :-)

    Cheers!

    ReplyDelete
  3. Thank you for the great insight! saved me a great deal of time. keep up the bloging and loging of data

    ReplyDelete
  4. Macports actually won't run if you update your OS. It won't even update itself the way it should -- 'port selfupdate' returns

    "Error: Current platform "darwin 15" does not match expected platform "darwin 14"
    Error: If you upgraded your OS, please follow the migration instructions: https://trac.macports.org/wiki/Migration
    OS platform mismatch
    while executing
    "mportinit ui_options global_options global_variations"
    Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch"

    The instructions at that URL call for you to run 'port' commands that won't run because any 'port' command returns the message to run the 'port' commands that won't run.

    Solution:

    rm -rf (long list of places 'port' stores stuff)
    install homebrew

    Well, except that 'homebrew' doesn't include a recipe for TortoiseHG, which is part of my everyday workflow. SIGH.

    Off to fetch macports source code and fix thed @#$%@#$%! thing by hacking its source code. GRRRR! I hate buggy code! I get paid to fix *MY* buggy code, not *OTHER PEOPLE'S* buggy code!

    ReplyDelete