The title here and the quote at the bottom of the page say that it's better than MacPorts but there doesn't seem to be any comparison between them other than that. The only thing I've seen people use to say that it's better is that it's written in Ruby, but that doesn't seem like a big deal. Is there a comparison of the two somewhere? It seems like the problem people have with MacPorts is that it's been around longer so there have been more chances for things to go wrong.
Homebrew — MacPorts driving you to drink? Try Homebrew
11–20 of 65 posts
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#12I can't recommend homebrew enough - I've been burned by macports and fink in the past, and so I had reverted to the time tested "just compile stuff by hand". Homebrew strikes a good balance between the raw, do it yourself approach and something as big and intermingled as macports.
What problems did you have with MacPorts?
Frequently, when actually needing to compile other things (outside of macports), Macports would be pulled in "magically" and cause issues (such as gettext and Python-core). Frequent issues debugging strange issues when trying to port install things, etc.
Homebrew does just enough to work, and get the job done and attempts to "fit in" with the OS I already have, versus making it's own sandbox off to the side.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#13I currently use MacPorts... just wondering why I should switch?
I haven't switched to Homebrew but the advantage is that MacPorts creates its own universe of libraries, whereas Homebrew uses what Mac OS X already comes with. This makes installs a lot faster.
MacPorts creates it's own universe because that's the only reliable way to do it. What will Homebrew do when Python gets updated by Apple, or when you want 2.6.10 and Apple only has 2.6.4? With Macports the situation is easily dealt with, with Homebrew it's not.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#14Earlier quoted context omitted.
What problems did you have with MacPorts?
Frequently, when actually needing to compile other things (outside of macports), Macports would be pulled in "magically" and cause issues (such as gettext and Python-core). Frequent issues debugging strange issues when trying to port install things, etc. Homebrew does just enough to work, and get the job done and attempts to "fit in" with the OS I already have, versus making it's own sandbox off to the side.
The problem with accidentally pulling in libraries seems unavoidable with Homebrew since it uses /usr/local. Is the lack of sandboxing what you think makes it better? This seems like exactly what you should be looking for.
While I agree that it would be nice to have seamless integration with the OS, having a completely separate installation helps with things like OS upgrades or when you need to use a different version of a library that is installed by the OS. Does Homebrew do anything to handle that kind of problem?
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#15Earlier quoted context omitted.
I haven't switched to Homebrew but the advantage is that MacPorts creates its own universe of libraries, whereas Homebrew uses what Mac OS X already comes with. This makes installs a lot faster.
MacPorts creates it's own universe because that's the only reliable way to do it. What will Homebrew do when Python gets updated by Apple, or when you want 2.6.10 and Apple only has 2.6.4? With Macports the situation is easily dealt with, with Homebrew it's not.
Homebrew targets specific versions of OS X (currently 10.5/10.6).
Within a released version of OS X, they don't tend to break backwards compatibility.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#16Earlier quoted context omitted.
I haven't switched to Homebrew but the advantage is that MacPorts creates its own universe of libraries, whereas Homebrew uses what Mac OS X already comes with. This makes installs a lot faster.
MacPorts creates it's own universe because that's the only reliable way to do it. What will Homebrew do when Python gets updated by Apple, or when you want 2.6.10 and Apple only has 2.6.4? With Macports the situation is easily dealt with, with Homebrew it's not.
"brew install python" works (and I've used it). In fact, I have a small pile of additional recipes locally for just doing custom, well-controlled compiles of Python.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#17Earlier quoted context omitted.
Frequently, when actually needing to compile other things (outside of macports), Macports would be pulled in "magically" and cause issues (such as gettext and Python-core). Frequent issues debugging strange issues when trying to port install things, etc. Homebrew does just enough to work, and get the job done and attempts to "fit in" with the OS I already have, versus making it's own sandbox off to the side.
The problem with accidentally pulling in libraries seems unavoidable with Homebrew since it uses /usr/local. Is the lack of sandboxing what you think makes it better? This seems like exactly what you should be looking for. While I agree that it would be nice to have seamless integration with the OS, having a completely separate installation helps with things like OS upgrades or when you need to use a different versio…
It can use /usr/local - and you can set it up so that /usr/local comes before the rest of your system as you need to. Yes, an entirely self-contained sandbox avoids this, but most of the time, I don't want that.
Like I said in a previous comment, most of the time I'd find myself compiling things by hand into /usr/local anyway.
Please! Use the system's provided libraries. If I need something newer, I'll brew install it myself. For me homebrew strikes a good balance between "compile it myself, damn it" and Macports/Fink. The formula are easy to hack and update (it's simple), and for the most part it just gets ourt of your way.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#18The title here and the quote at the bottom of the page say that it's better than MacPorts but there doesn't seem to be any comparison between them other than that. The only thing I've seen people use to say that it's better is that it's written in Ruby, but that doesn't seem like a big deal. Is there a comparison of the two somewhere? It seems like the problem people have with MacPorts is that it's been around longer…
I hated having to download 800mb of dependencies to install something simple. I already have Perl or lib(whatever); I don't need you to download it and install it.
I get the reliability argument (i.e., the only way to guarantee stuff builds right is to manage it yourself), but that's a problem with any platform where you might compile things alongside the package manager. So, let me manage that. I don't need a package manager to argue with me about what I want installed.
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#19Earlier quoted context omitted.
Frequently, when actually needing to compile other things (outside of macports), Macports would be pulled in "magically" and cause issues (such as gettext and Python-core). Frequent issues debugging strange issues when trying to port install things, etc. Homebrew does just enough to work, and get the job done and attempts to "fit in" with the OS I already have, versus making it's own sandbox off to the side.
The problem with accidentally pulling in libraries seems unavoidable with Homebrew since it uses /usr/local. Is the lack of sandboxing what you think makes it better? This seems like exactly what you should be looking for. While I agree that it would be nice to have seamless integration with the OS, having a completely separate installation helps with things like OS upgrades or when you need to use a different versio…
You don't have to use /usr/local/
Re: Homebrew — MacPorts driving you to drink? Try Homebrew
#20A better way to use all those unix tools is to just run Ubuntu in a VM and develop there, or just replace MacOS with Ubuntu entirely.