
Homebrew is a new package management system for OS X based on git + ruby - blasdel
http://github.com/mxcl/homebrew/tree
======
blasdel
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
_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.

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

~~~
blasdel
Naively syncing ~/bin only works when all your systems run the same kernel, on
the same architecture, using intercompatible versions of system libraries and
programming language runtimes. It also doesn't solve the package management
problem at all!

With homebrew, you could sync just the dotfiles and the list of installed
packages, and let it take care of installing/upgrading packages on each
machine. It'd be even better if it was smart enough to not shadow system
packages when they are present+adequate.

~~~
silentbicycle
> That only works when all your systems run the same kernel, on the same
> architecture, using intercompatible versions of system libraries

If dotfiles aren't compatible across OS kernels, you're doing something wrong.
I keep scripts in ~/bin under VC, but with anything that needs to be compiled
I just track the source and build with make (or emacs, etc.). You don't need
to put everything in ~/bin in the repository!

From the summary, I don't really see how the system would work transparently
across OS X, Linux, and BSD. It looks like it expects git + Ruby + OS X, and I
don't use the latter two. (I prefer Lua and OpenBSD, respectively, but that's
me.) Also, I work with i386, amd64, and occasionally sparc, and the platform
thing isn't an issue since I'm not syncing binaries.

~~~
blasdel
Yes, right now homebrew is specific to Mac OS 10.5+ -- the second paragraph of
my original comment is pining for portability, so it could be used on shell
accounts and beyond.

A _major_ use case is the ability for your app to be able to pull in it's own
sandboxed dependencies in a crossplatform way -- so anyone can develop on
their macbook independently of their system is set up, and deploy on any
worthwhile server regardless of its setup.

gem does a pretty damn good job of this for Ruby libraries, but it doesn't
help at all for the native libraries and utilities that the gems are wrappers
around :)

~~~
silentbicycle
Well, there's the Unix distro package system _and_ another repository for Ruby
gems _and_ CPAN _and_ LuaRocks _and_ Hackage and ... They keep stepping on
each others' toes, but I'm not sure the solution is to add even more mutually
incompatible packaging systems. By their nature, they need to see the system
(inc. what dependencies are available) as a whole to be really useful, and
fragmenting that picture makes the situation worse for all involved. (On
second reading, it looks like it's designed to try to work with CPAN et al, so
that's an improvement.)

It would be nice if it actually worked, but coming up with a perfectly
portable global packaging system would be hard enough if it was working across
platforms for one vendor, let alone the big mob that is the open source world.

------
hyperbovine
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
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.

~~~
blasdel
...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.

------
apinstein
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
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.

~~~
jvdh
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.

~~~
masklinn
> It's only since the last two or three releases of OS X that they included
> halfway decent versions of them.

And even then, sadly the pretty decent versions don't get updated (OSX 10.6
comes with Python 2.6.1… 2.6.2 was released in April…), so you're essentially
SOL between two versions of OSX.

------
yangyang
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.

~~~
mxcl
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.

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

------
tfh

      > 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!

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

~~~
mattyb
Seriously?

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

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

~~~
blasdel
You asked the equivalent of _'how is babby formed?'_

------
erlanger
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
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.

