MacPorts 2.0 with Lion support now available(trac.macports.org)
trac.macports.org
MacPorts 2.0 with Lion support now available
https://trac.macports.org/post/macports-200-now-available/
42 comments
Upgrading to Lion is a great time to make the switch to Homebrew: http://mxcl.github.com/homebrew/
Benefits over MacPorts? Which has more up-to-date packages?
I made the switch to homebrew fairly recently (within the last two months).
Things I like:
* I install everything to ~/.brew/ and it works great. I did _not_ like their documented recommendation to install everything to /usr/local and chown it as your user. I have yet to run into any issues installing to my home dir.
* Installs of things have fewer deps, or at least perceived, compared to macports. Nice to not have a separate copy of everything. I haven't run into issues (yet!) where an OS update makes something puke, so this could be a problem down the road, but so far so good.
* Upgrades are very simple: brew update / brew upgrade
* Toolset is easy to work with.
* timely updates
Things I like:
* I install everything to ~/.brew/ and it works great. I did _not_ like their documented recommendation to install everything to /usr/local and chown it as your user. I have yet to run into any issues installing to my home dir.
* Installs of things have fewer deps, or at least perceived, compared to macports. Nice to not have a separate copy of everything. I haven't run into issues (yet!) where an OS update makes something puke, so this could be a problem down the road, but so far so good.
* Upgrades are very simple: brew update / brew upgrade
* Toolset is easy to work with.
* timely updates
I'd go for sheer package numbers, and also MacPorts traditionally has had much better support for Python packages, and the rudimentary python_select.
Macports says they have 8199 packages. Brew has 1626 by my unscientific count (hint: $('table.tree-browser tr').length ).
A major difference is in how packages are installed. Brew by default will use native OS X packages. Macports installs all dependencies to /opt/local. So a trivial install for Brew could lead to a long install in Macports. I've had Macports build GCC.
But this new version is supposed to allow for pre-compiled binaries. So maybe a lot of that beef will disappear?
Macports says they have 8199 packages. Brew has 1626 by my unscientific count (hint: $('table.tree-browser tr').length ).
A major difference is in how packages are installed. Brew by default will use native OS X packages. Macports installs all dependencies to /opt/local. So a trivial install for Brew could lead to a long install in Macports. I've had Macports build GCC.
But this new version is supposed to allow for pre-compiled binaries. So maybe a lot of that beef will disappear?
Maybe things have changed but I switched from MacPorts to homebrew in the early days of homebrew (2009?) because it was way easier to install.
MacPort's package installer tools mystified me. Homebrew could be improved too, but is better.
Finally, homebrew seems more open to contributions and because they use GitHub, it's very easy to contribute new packages and the high level of activity on Homebrew reflects that. I briefly looked at what it would take to contribute to MacPorts and it was harder.
MacPort's package installer tools mystified me. Homebrew could be improved too, but is better.
Finally, homebrew seems more open to contributions and because they use GitHub, it's very easy to contribute new packages and the high level of activity on Homebrew reflects that. I briefly looked at what it would take to contribute to MacPorts and it was harder.
1) Brew doesn't hide my stuff in /opt/macports/opt/package/ports/port/python/etc/etc/etc
2) Brew packages are simple to make and inspect. Many people make and inspect them. Bug fixes happen quickly.
2) Brew packages are simple to make and inspect. Many people make and inspect them. Bug fixes happen quickly.
Agreed with (2).
I actively create patches and submit it to them whenever I run into a problem, and I will keep doing so, because it's typically only a few days until it gets merged.
How I got into it, was the nifty searching of Github issues that Homebrew does for existing issues when you have a compilation error. One way to get people to report bugs is to show them you care..
I actively create patches and submit it to them whenever I run into a problem, and I will keep doing so, because it's typically only a few days until it gets merged.
How I got into it, was the nifty searching of Github issues that Homebrew does for existing issues when you have a compilation error. One way to get people to report bugs is to show them you care..
Homebrew tries to reuse system packages as much as possible. MacPorts comes with its own everything.
Homebrew tends to have fresher packages---new versions of popular packages are usually updated within hours.
Haven't look back to MacPorts since switched to Homebrew two years ago.
Homebrew tends to have fresher packages---new versions of popular packages are usually updated within hours.
Haven't look back to MacPorts since switched to Homebrew two years ago.
Brew doesn't install the whole universe and take hours to install a small utility. MacPorts does.
> Brew doesn't install the whole universe and take hours to install a small utility. MacPorts does.
Confirming that - my new MacPorts 2 install installed perl and ncurses just to get ipython.
Confirming that - my new MacPorts 2 install installed perl and ncurses just to get ipython.
And, even worse, xorg and xdmcp to get py25-pil.
Does brew compile from source? That is one of the most frustrating aspects of macports, for example I was trying to install a simple musical ear training tool the other day and it went to compile GCC. Argh!
The thing with MacPorts is, basically, you're installing a parallel universe that doesn't know about the software your system already had. So it has to bootstrap completely from scratch, including its own toolchain, basic libraries, etc.
Once you get all that, it goes faster, but the first time you go to install something simple you're basically going to walk away for a couple hours while it sets up its own little world.
Once you get all that, it goes faster, but the first time you go to install something simple you're basically going to walk away for a couple hours while it sets up its own little world.
Yes, in most cases, but most packages have minimal dependencies due to Homebrew's "use what OS X provides" philosophy, i.e., the XCode toolchain (Homebrew doesn't even have a package for GCC).
[deleted]
The benefit is that Homebrew uses what you already have in the system, without creating its own separate world where it rebuilds everything even if a perfectly working version is already provided.
MacPorts used to do this, and then stopped because the copy on the system sometimes wasn't "a perfectly working version" and by virtue of being tied to an entire OS update caused giant incompatibilities (as you had to deal with, simultaneously, broken old versions and broken new versions existing in the ecosystem).
Well, either those are corner cases or the Homebrew guys are doing a great job because I've never had a problem. Not a heavy user though. Before Homebrew I used to build my own packages because I tried and couldn't stand Fink or MacPorts.
I think Homebrew has been around for about two years now; it came out during the Mac OS 10.5 era. That means that only last week has it even gone through a second major release of the OS.
MacPorts, formally DarwinPorts, has been around for nine years, and has been post-1.0 for the last six. I am pretty certain that it came out during the Mac OS 10.1 era, and at the time supported down to 10.0.
Given this stark contrast, to compare the compatibility complexity experience of MacPorts to Homebrew with the statement "I've never had a problem" is nothing less than hubris.
Seriously, the history of every package management system (including such stalwarts as RPM, APT, MacPorts, and even rubygems) is the same: they start off with the attitude "why is this so complex" and then get to find out over the next decade exactly why those things are so complex.
Honestly: why does it matter oh so very much to everyone that you have to rebuild a few more packages? Isn't this just a problem of not having binary packages? If so, rather than sit around and build Homebrew, someone should have just contributed some bandwidth back to Fink.
MacPorts, formally DarwinPorts, has been around for nine years, and has been post-1.0 for the last six. I am pretty certain that it came out during the Mac OS 10.1 era, and at the time supported down to 10.0.
Given this stark contrast, to compare the compatibility complexity experience of MacPorts to Homebrew with the statement "I've never had a problem" is nothing less than hubris.
Seriously, the history of every package management system (including such stalwarts as RPM, APT, MacPorts, and even rubygems) is the same: they start off with the attitude "why is this so complex" and then get to find out over the next decade exactly why those things are so complex.
Honestly: why does it matter oh so very much to everyone that you have to rebuild a few more packages? Isn't this just a problem of not having binary packages? If so, rather than sit around and build Homebrew, someone should have just contributed some bandwidth back to Fink.
Giving this a try now. While I'm waiting for XCode to download, can anyone comment on the best way to get Apache httpd running on OSX? Is there a Homebrew package for this?
I use Apache to front Tomcat on a linux server, but it would be really handy to be able to test stuff locally on my Mac before copying changes up to the server.
I use Apache to front Tomcat on a linux server, but it would be really handy to be able to test stuff locally on my Mac before copying changes up to the server.
Im not sure about Lion, but OSX comes with built in apache server. Goto System Preferences > Sharing > Web Sharing
Ah, I knew that Web Sharing used Apache, but I didn't realize that it was packaged in such a way as to be usable for stuff beyond Web Sharing. The conf files seem to live in /etc.apache2. Thanks for that.
Indeed, Apache is included.
I am intrigued by the overwhelming support for Homebrew here -- is there a web resource for package lists so I can see if it will work for me? I haven't been able to google one up.
I don't use macports a lot, I think the biggest things I have installed are Python 2.7, PIL, and Hg.
I don't use macports a lot, I think the biggest things I have installed are Python 2.7, PIL, and Hg.
Homebrew is just a Ruby project in git so all the packages (or formulas) are just rb files inside the project:
https://github.com/mxcl/homebrew/tree/master/Library/Formula
They usually only provide the most recent stable version of each project but you can find other formulas on the web and just run:
brew install [url]
https://github.com/mxcl/homebrew/tree/master/Library/Formula
They usually only provide the most recent stable version of each project but you can find other formulas on the web and just run:
brew install [url]
[deleted]
I've been a happy homebrew user since it launched - anyone care to comment on the benefits/improvements of MacPorts V2 over homebrew?
Last time I looked, MacPorts had a more paranoid approach to dependencies. That can be good and bad. Homebrew can be easier to use, until you run into a corner case that trips it up. MacPorts can be frustrating in how many dependencies it will insist on installing its own version even though the system-provided version might have worked.
I've gone back and forth. For a while homebrew could install a working GHC for me while I wasn't having any luck with MacPorts. Later something else caused me to switch back to MacPorts. Neither is perfect. Even MacPorts only allows dependencies at the package level, without regard to variants, or versions, if I recall correctly.
I've gone back and forth. For a while homebrew could install a working GHC for me while I wasn't having any luck with MacPorts. Later something else caused me to switch back to MacPorts. Neither is perfect. Even MacPorts only allows dependencies at the package level, without regard to variants, or versions, if I recall correctly.
There are some variant packages, eg, php5.2.x vs 5.3.x
For those of us who haven't hit homebrew's edge cases in years of use are probably fine to keep using homebrew. If it ain't broke...
I just want it to install packages. It does that so I'm happy.
I just want it to install packages. It does that so I'm happy.
Familiarity in my case -- for my legacy Mac servers I'm sticking with what both I and my boxen know. :) New servers will all be running Linux, so it'll be with the package manager for that distro, likely Debian.
Don't care. Switched to Homebrew. Much happier - no double-installs unless I want to, faster fixes, and waaaaay faster interaction. How MacPorts manages to run so slowly is beyond me.
MacPorts has been annoying since day one, but it worked where there was nothing else truly competitive (Fink? Everything bad in MP, plus even slower updates. Only benefit is the sometimes-functional binary installs). Now we have Homebrew, and it's way better, if it has fewer legacy recipes (though not always).
MacPorts has been annoying since day one, but it worked where there was nothing else truly competitive (Fink? Everything bad in MP, plus even slower updates. Only benefit is the sometimes-functional binary installs). Now we have Homebrew, and it's way better, if it has fewer legacy recipes (though not always).
MacPorts 2.0 fixed all of the issues that I was having under Lion with 1.9.0. Thanks for upgrading guys! :)
To upgrade, make sure you install Xcode 4.1 via the App Store (free). That'll provide GCC. After:
To upgrade, make sure you install Xcode 4.1 via the App Store (free). That'll provide GCC. After:
$ sudo port selfupdate
$ sudo port upgrade outdated
New Mac user here (~5+ weeks). Just echoing what others have said about Homebrew here so far:
After some research, MacPorts looked painful to install/maintain so I went with Homebrew seeing as it looked like there was more activity going on there as well as being easy to contribute to via github and what looked like a short tutorial on creating and contributing your own packages (+ a bit of ruby knowledge) if I felt the need.
I like it simple. :)
After some research, MacPorts looked painful to install/maintain so I went with Homebrew seeing as it looked like there was more activity going on there as well as being easy to contribute to via github and what looked like a short tutorial on creating and contributing your own packages (+ a bit of ruby knowledge) if I felt the need.
I like it simple. :)
As a point of contrast - I've been using OS X for about 8 weeks and I had some problems when first installing Homebrew (I do not remember the specifics, but I seem to recall some issues with installing iPython and the modules I wanted to use) - and since giving MacPorts a try I've really had no issues with it.
My only advice on MacPorts is to always do a dry-run before installing packages (port -y install), to see what dependencies will be dragged in - installing num.py wanted to re-compile a numerical computing package from scratch which I had to kill after a few hours of compilation (with no visible progress on the command line).
My only advice on MacPorts is to always do a dry-run before installing packages (port -y install), to see what dependencies will be dragged in - installing num.py wanted to re-compile a numerical computing package from scratch which I had to kill after a few hours of compilation (with no visible progress on the command line).
Had a problem (Macbook Pro, which I bought in Jan-2008) with upgrading to 2.0
After "debugging"-it, e.g: port -v self update
it gave me some mysterious problem of SQLite missing 64-bit version from... /Library/Mono.Framework/.../sqlite.dylib - don't remember the details.
Found some notes how to uninstall mono from their site (little script), and then "port selfupdate" went fine.
After "debugging"-it, e.g: port -v self update
it gave me some mysterious problem of SQLite missing 64-bit version from... /Library/Mono.Framework/.../sqlite.dylib - don't remember the details.
Found some notes how to uninstall mono from their site (little script), and then "port selfupdate" went fine.
Congrats to the MacPorts team for 2.0 and lion support. It's unusual in a HN thread that most of the talk is about an alternative to the posted topic. However, I have to tip my hat to the work the MP team but it would be irresponsible to recommend it over Homebrew. Homebrew is what a package manager should feel like.
Thanks to everyone involved!
[deleted]
Is there any chance MacPorts would get the Terminal proxy icon to work with the fish shell?