Homebrew is a new package management system for OS X based on git + ruby

by blasdel • 17 years ago

99 46 17 years ago

blasdel10• 17 years ago

Someone's finally gone and written the package manager I've always wanted -- one that can just run in your home directory unprivileged and reuse most of the system packages. Also source-based and plays along with upstream by default!

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on servers everywhere (though a major complication is Debian's obnoxious segregation of headers into separate packages)

jon_dahl• 17 years ago

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on servers everywhere

Amen. That could be hugely powerful.

silentbicycle4• 17 years ago

For home directory stuff, I've found that just git can be quite sufficient for tracking and syncing dotfiles and ~/bin.

mxcl4• 17 years ago

Hi I wrote Homebrew, and this is one of my goals, I've always wanted installing from source on Linux to get package management too. I do a lot of cross platform dev, and would also love for this to work on Windows. But that may be too lofty a goal.

I also added the feature where you can specify a git:// or svn:// protocol for a formula so you can easily keep up with HEAD development for your favourite project.

lamby2• 17 years ago

"a major complication is Debian's obnoxious segregation of headers into separate packages"

What's so obnoxious about this? The -dev packages will depend on libfooSONAME (and have far more stable names) so it's hardly more effort to keep them installed.

blasdel10• 17 years ago

I don't know of any way to have apt always pull them in as dependencies, so I constantly find myself installing them manually.

Debian's policy of splitting all features off into their own packages (or disabling them entirely for ideological reasons), and having duplicates of many packages (with mutually-exclusive dependents) constantly fucks with me. I can't ever depend on its dependency tracking to actually give me what I want. It's not a good sign when all the digg-bait walkthroughs always instruct you to paste in a huge list of packages.

charlesju4• 17 years ago

How difficult is it to port something from Unix to BSD?

mattyb• 17 years ago

Seriously?

http://en.wikipedia.org/wiki/Berkeley_Software_Distribution

charlesju4• 17 years ago

How did your answer get up-voted 7 times. This confuses me; you put me down AND didn't answer my question.

silentbicycle4• 17 years ago

It's not that hard, provided the people who wrote it are aware that other Unices exist besides Linux.

(I've done a bit of porting to OpenBSD. It's a pet peeve of mine when people hardcode references to bash for no good reason.)

blasdel10• 17 years ago

It doesn't help matters at all that bash leaks bashism-support when run as /bin/sh -- it's much better that people specify bash than ship scripts that falsely claim to be bourne-compatible (since they are unlikely to test against a pure-bourne shell).

Not having a /bin/bash a losing battle -- it's way too late to get people to use the theoretically more correct #!/usr/bin/env bash just because the greybeard unices don't ship with it (despite shipping with plenty of other GPL software) and their package managers put it (when they are nice) in /usr/local/bin

Edit: That's not a diss on the greybeard unices -- I used FreeBSD and loved it dearly for years. I actually really like that they segregate all user-installed packages into a seperate root at /usr/local/ -- but for practical reasons I always make symlinks for binaries with well known locations (to use the robots.txt / favicon.ico pejorative).

charlesju4• 17 years ago

Did I seriously get down-voted for asking a legitimate technical question? That's an abusive down-vote in my opinion, people should be able to ask technical questions without being ridiculed because they don't know the specific inner-workings of different OS kernels.

jibiki• 17 years ago

Um, BSD is a unix, right? Did you mean to ask about porting from Linux to BSD?

zzkt• 17 years ago

It's about as easy as translating from American into English.

apinstein• 17 years ago

From reading the article it doesn't seem like it does a whole lot more than MacPorts... most of what is discussed is possible by tweaking port settings (prefix, partial/custom builds, having multiple versions of things, etc).

Maybe the CLI app exposes some of this a little more easily? I am not sure but I am curious why they built an entirely new setup rather than just improving/fixing up MacPorts...

Nonetheless a promising start!

telemachos• 17 years ago

The philosophy of Homebrew is radically different from MacPorts or Fink. Homebrew tries to work as far as possible with the pre-installed big items (Perl, Ruby, Python). It drags in as few dependencies as possible, in general, from what I can tell.

Both Fink and MacPorts, on the other hand, install virtually an entire second world of software - parallel to the built-in Apple stuff - in their respective sub-directories (/sw for Fink and /opt/local for MacPorts).

If you install Getmail with MacPorts, for example, you instantly drag in a full Python installation as a dependency (even though OSX already has Python installed). Similarly, if you install Weechat with Perl support, MacPorts installs its own version of Perl to build Weechat against. There are pros and cons, I think, to the Homebrew and MacPorts/Fink methods, but they are very different.

davidmathers• 17 years ago

There was an attempt to get gentoo's portage working on OS X with the same philosophy, but they gave up and said that it had been a mistake to go in that direction and not just install parallel copies of everything.

I don't know the specific problems they had.

jvdh2• 17 years ago

Historically OS X shipped with ancient versions of Python that were not always complete. Same with Perl and others. It's only since the last two or three releases of OS X that they included halfway decent versions of them.

I agree that it may seems somewhat stupid now, but there was (and perhaps still is) a very good reason for installing them separately.

rmaccloy• 17 years ago

Well, it looks like the entire footprint (Ruby LOC) on github is smaller than port.tcl in MacPorts, so I imagine it seemed more approachable.

erlanger• 17 years ago

It looks cool, but I wish the early adopters the best. It will be a little while before I let this near my system.

dasil003• 17 years ago

When I buy a new MBP I'm going to use this, it's pretty much perfect for my use case and I'm not much of an early adopter as far as developers go. I've tried MacPorts and Fink, but they always inevitably had some issue that made me switch back to manually compiling things to /usr/local.

Homebrew seems like a very nice thin layer over manual builds. Some people maybe can't live without dependency resolution, but the lack of it is one of the main reasons that I'm confident that Homebrew is simple enough that it will help me with a lot of the mundane and annoying issues (ie. getting compile flags right for OS X, etc) without hamstringing me when I need to go outside the system.

hyperbovine• 17 years ago

Any idea why the Mac crowd seems to shun binary packages? Before playing with MacPorts I wasn't even aware of the concept of a source-only package manager. Each time I spend 20 minutes recompiling the entire xorg dependency chain because the minor version number got bumped from .1 to .2, I cringe at the thought of how many CPU cycles are being wasted all over the world to produce essentially the same thing.

spicyj• 17 years ago

Simply because there isn't an up-to-date package management system that provides binary packages. Typing "brew install <whatever>" is a million times easier than searching out the software package's website and hunting around for a binary package that's for your OS version.

blasdel10• 17 years ago

...and that works together with all the dependencies you've also installed, and the set of configure --options they were built with.

It's also a strong guarantee that if the package is built any different than the upstream default, you know exactly what changes are being made, since they happen on your machine.

jvdh2• 17 years ago

For the last couple of years there have been different CPUs for Macs. First we had the G4, then the G5, followed by the switch to Intel. And even for the Intels there's lots of different subtypes.

And of course now with the switch to Snow Leopard we've got the 64-bit issue as well.

Yes, it does take a while, but these days it doesn't take that long anymore.

jcromartie• 17 years ago

Yeah, but as of right now you could basically call it PPC/Intel, and most users are probably running Intel. Binaries (universal or not) are good enough for every single application distributed for the Mac platform. Why would command-line tools or libraries need to be any different?

masklinn2• 17 years ago

> Any idea why the Mac crowd seems to shun binary packages?

4 different architectures (PPC/32b, PPC/64, Intel/32 and Intel/64) are probably hell on a binary-only package manager. Source-only is simpler and lighter on the architecture side, though it's much heavier on the client one.

Fink does binary packages though, I think.

there• 17 years ago

the openbsd project builds 1700 to 5600 binary packages for each of 12 architectures on a weekly/monthly basis and continuously mirrors them throughout dozens of ftp sites. building a few dozen or even a few hundred packages for 4 architectures isn't that hard, it's just a matter of resources. someone has to have 4 of those machines sitting around doing nothing but building packages, uploading them somewhere, and then take the time to fix ports and dependencies that don't build on certain architectures.

fwiw, i use fink on mac os and it supports binary packages. many of the ports in its stable branch are available as binary packages.

mxcl4• 17 years ago

Personally there were two reasons:

1) I don't want bandwidth costs

2) It's much harder to get contribution for a binary system (I expect). If you're installing foo and it doesn't work for some reason you probably won't want to install Xcode and Homebrew-dev in order to try and fix it. When you're installing from source you're already a `brew edit foo && git push` away from helping fix it.

It's also worth noting that most packages don't have dependencies in Homebrew. This is because we don't duplicate what is already there and OS X comes with quite a lot of the common low level libraries. So compiling foo takes significantly less time than it does with Macports.

tfh• 17 years ago

  > Homebrew helps get you chicks
  > here's no conclusive scientific evidence as yet,
  but I firmly believe it's just a matter of time and statistics.

Geek humour is awesome!

yangyang2• 17 years ago

Interesting.

I tend to just build stuff myself from source and use GNU stow. I'm amazed I hear so little about stow, it's so useful.

I just configure with a prefix arg of something like /usr/local/stow/package-version, then use stow to install in /usr/local/{bin,etc,lib} etc. etc. Works equally well in one's home directory, which is what I used to do at work.

mxcl4• 17 years ago

Heh, it's handy I didn't know about this, or I might never have started Homebrew.

Still at this point our ambitions are quite vast, so I expect Homebrew will prove more useful in the long run.

yangyang2• 17 years ago

I'm sure it will. I'm generally only installing fairly small packages, with bigger stuff the stow method would probably get tiresome.

Homebrew is a new package management system for OS X based on git + ruby

Related Stories