On Jan 28, 2014, at 12:14 PM, Geoff Oxberry <[email protected]> wrote:
> > > > On Tue, Jan 28, 2014 at 9:10 AM, Sean Farley <[email protected]> > wrote: > > [email protected] writes: > > > To echo what Aron said, I wouldn't point people at the > > hpc.sourceforge.netbuilds. They do install directly into /usr/bin, and > > it's a pain in the ass > > Satish is probably right here about the build location. It's been three or > four years since I've installed it this way. I stand by that it's still > difficult to revert. I actually tried this method because of PETSc and > regretted it because the experience was terrible. Using a package manager is > more maintainable, and I think PETSc's recommendation of the hpc.sourceforge > build is a disservice to both users and to PETSc's excellent reputation. I think package managers for Mac OS are a disservice to the community and recommend not using them. (See all the discussions in these emails about how they fuck up). Barry > > > to undo. The R/AT&T build of gcc was better, but also installed into > > /usr/bin, and was also a pain in the ass to uninstall. > > It's impossible to uninstall since it overwrites gcc binaries. So you > have to reinstall Xcode / Command Line Tools to go back. > > Functionally, that's the same thing. Again, it's been three or four years. > > > The biggest reason I don't recommend the gfortran binary from R or from > hpc.sourceforge.net is that it puts you in a spot of maintaining your > own stack. Now that I've integrated all my custom modifications into > MacPorts-proper, I can finally start pointing people to that. > > That's not to say that I think MacPorts is the best solution for > everyone. I just found that I could get MacPorts to do what I wanted > with the least amount of work. > > That was not my experience. > > > Having used both MacPorts (2010-2012) and Homebrew (2012-present), I find > > Homebrew to be a better experience, especially if you only need a small > > number of packages for development. MacPorts used to insist on its own > > stack, which meant that if you wanted gfortran, you also had to install > > many other packages. > > MacPorts still does this so that it can get a sane stack that is > invariant of OS versions and processor type (we still support ppc > :-(). A year or two ago we got buildbots so that most people can benefit > from binary downloads. > > Homebrew and MacPorts use different philosophies. Homebrew relies more on the > system stack, which led to all sorts of problems when Mavericks came out. > Most of these seemed to be due to the clang transition to libc++, or to > C++11. Mike McQuaid, Misty DeMeo, Jack Nagel, and Adam Vandenburg have been > doing an excellent job fixing bugs. > > Over the last year, I've finally been able to become maintainer for a > lot (~100) of the scientific packages in MacPorts (including PETSc and > friends) with the goal of improving the > > I used to follow that. It seemed like it took a long time for MacPorts to > respond to bug reports, and they weren't particularly keen on external > contributions. I haven't had that issue with Homebrew; all their core devs > are very engaged. > > > I generally developed using gcc 4.2 because I found cross-version linking > > to be a pain in the ass. I've also installed gcc 4.8 via the > > homebrew/versions tap and that's worked well, too. > > My problem with homebrew's use of compilers is that I couldn't specify > (easily) a way to install a package with either compiler and then switch > between the two packages (a la PETSC_ARCH). > > You're right; MacPorts does that better. There may be a way to do that with > flags. Some formulas in Homebrew build with gcc instead of clang. At worst, > you could maintain your own taps of formulas that you want to compile with > specific compilers. It would be an interesting idea to pitch. > > > Python is sort of broken in both MacPorts and Homebrew. If you look at the > > GitHub issues, there's been a lot of traffic related to Python in Homebrew > > lately because they completely revamped how they handle Python in their > > build recipes, which then broke some Python packages installed via > > Homebrew. Last I checked, Python was more broken in MacPorts and required > > lots of hacks to get things to work, but it's been a while since I've used > > MacPorts. I think the best policy is to rely on the package manager for as > > little Python software as possible, and install the rest of your Python > > stack in an isolated manner; I use pyenv, pip, & virtualenv. Conda sort of > > does something similar, but I feel like conda is a great build system with > > too many other responsibilities. > > Woah, woah, woah there. Python is broken? I've been using it in MacPorts > for years with no issues. If you can reproduce anything or point me to > the tickets on trac.macports.org, I can try to fix them. > > Aron already went over this in his comments on the Scientific Python stack. > > I've basically stopped using MacPorts as of two years ago because I found > that to make things work, I had to repeatedly kludge around things, making > building software from scratch quite painful. I think I submitted maybe one > or two tickets to MacPorts, and didn't get much of a response. I don't plan > on resurrecting my old install just to file bug reports. I switched to > Homebrew because the UX in MacPorts was getting miserable, it's written in > Ruby (not Tcl), they're much more welcoming about contributions (submitting a > PR was painless), and there's much more of a community there. I don't need to > kludge things, and they do an excellent job of responding to bugs. > > I applaud what MacPorts is doing, and as a former user, my biggest suggestion > would be to make it a little more clear that MacPorts values its user > community. There are some bug reports that go unresolved for a year or more, > which makes it hard to stick with MacPorts if you're one of the users that > keeps dealing with that bug. MacPorts also gives off the impression that it's > hard to contribute (Homebrew has 3450 contributors according to GitHub, and > is GitHub's most starred/forked repo; MacPorts has 182 contributors according > to Ohloh). There are a lot of similar complaints in "Homebrew vs MacPorts" > posts, which is why Homebrew seems to be eating MacPorts' lunch, despite > MacPorts' big head start, and initially far superior feature set. > > -- > Geoffrey Oxberry, Ph.D., E.I.T. > [email protected]
