Hacker News Reader

Comment by lloeki | Hacker News Reader

1) You could also create some wrapper scripts setting the path, or have someting inspired by virtualenv handle it, or maybe different terminal profiles. Those breakings really are edge cases.

2) Don't put them in the PATH. They're prefixed with 'g' so you can make an non-prefixed alias for your interactive shell, and use the prefixed variant in your scripts if need be. If you write portable scripts you're either using common features or use some vars for those utils, aren't you?

3) g++? that's not in homebrew...

Honestly though, MacPorts is a real pain. That's why I worked with others to bring Arch's pacman on OSX (dubbed ArchOSX) some years ago, but binary hosting was proving being a chore, and then Homebrew started taking off, and in my case Just Works.

View on HN

Homebrew does have binary packages (we call them bottles).

I'm the guy who implemented the feature and I am realising that as I didn't shout very loudly people don't realise that it exists.

For example Qt has a bottle: https://github.com/mxcl/homebrew/blob/master/Library/Formula...

The reason we aren't doing this for more packages is basically people power and hosting (as I'm not sure Sourceforge would be happy we hosting the number of binaries we'd want to have).

Hope that explains a bit. Feel free to comment if you think we're taking a good/bad approach here.

Hundreds of organizations donate mirror space to linux distributions (e.g. http://www.debian.org/mirror/list). I'm sure some of them would provide space to homebrew.

    3) g++? that's not in homebrew...

He probably meant GCC, which does have recipes in Homebrew.

    Homebrew started taking off, and in 
    my case Just Works

This is the first time I ever heard anyone saying it.

In general Homebrew did a good job for me, but it did break on me a couple of times. And when it did, fixing it caused me a lot of stress, because in the end it's really not much better than "./configure && make && sudo make install".

What I don't understand is how come we can't have binary repositories, like Debian's. Certainly Debian has to handle much more architectures and the number of packages contained is really huge. So how come there isn't such an alternative for Mac OS X? Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

I believe Fink provides binaries.

If you are attached to binary packages, there's always fink which might even predate Macports.

Unfortunately, building the packages and then keeping them current takes quite a bit of infrastructure which is why fink's binary packages are really outdated at times.

The other issue is with runtime-dependencies: Self-compiling packages gives you the freedom to, say, build vim without X11 support. With binary packages, the maintainer (or the packaging system) must create n packages for n possible combinations (if the project doesn't have some dynamic-library based plugin system) which is, again problematic from a resource-requirement perspective.

That being said, if debian can do it for around 30,000 packages on almost as many architectures as OSX has mere hardware models, why can't OSX do it? With all the app stores and cloud services, Apple is big on 'quite a bit of infrastructure'.

Because Apple don't provide these package management tools, volunteering third-parties do.

Apple are never going to provide Linux-style package management tools because the market for them is minuscule compared to Apple's real market: normal people. For normal people, there's the App Store.

while I agree, the point is moot as this talks about developers. So yes, apple did not make a package management tool. That pisses developers off. Makes no difference because you suck it up if you want to develop for mac/ios.

Its kind of like developing on windows, for windows, gota do what u gotta do.

It may not have started out that way (but it may have, I'm not sure), but MacPorts is an Apple hosted project: http://www.macosforge.org/

What they don't host is the source or compiled versions of any of the packages in the MacPorts repository - potentially for the same reason they include no GPLv3 software in their OS.

It would be perfectly safe for Apple to offer the resources required by the MacPorts project to function adequately.

In some cases, they do. This is especially apparent if you're still using MacPort with PPC, as most of the packages it pulls down are form the MacPorts servers.

Developers aren't "normal people" then? If that's seriously the attitude Apple takes towards its developer community ("no, we won't give you the software you need, get it from the crappy community projects") then why do you put up with it?

It seems like the OP's point is pretty valid to me. I use an OS that gives me what I need to do my job.

> Developers aren't "normal people" then?

No. They aren't. Developers have needs far greater than that of your average everyday user. Apple sells a machine that is the best possible for the greatest number of users, and doesn't really cater to niche markets. I don't get what's surprising about this.

Because even developers do "normal people" things. There are a lot of trade offs, but in my experience Apple provides the best middle-of-the-road machines.

Linux and Windows feel like they exist on opposite ends of the spectrum.

You could always try to revive the Arch OS X project (it was 100% functionally working end-to-end) if you want, but it failed in favor of Homebrew for a reason: no one seems to want to assume the cost (both in time and money) of the binary side of things (hosting, building distributable packages, uploading, etc...).

    Homebrew started taking off, and in 
    my case Just Works

This is the first time I ever heard anyone saying it.

Here's another: it worked for me perfectly, in and of itself. I use pianobar, which frequently updates (due to Pandora changing protocol or keys), and I often have to do some recipe editing to get that latest update, but it seemed simple enough. Since the brew update list doesn't get fixes anything like as fast as the pianobar author updates when something breaks, it seems to me that having to wait for someone to actually compile pianobar elsewhere would mean that I'd have to wait days for the packaged version.

This is the first time I ever heard anyone saying it.

What do you mean? People are saying that about homebrew all the time. Have you read on blog posts on it?

It just worked for me too, and I have around 20-25 packages installed.

Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

So that an OS upgrade, in which Apple tends to include arbitrary upgrades to system libraries (or the Ruby/Python etc version), doesn't break whatever you installed with Homebrew/MacPorts.

FWIW nowadays MacPorts does install binaries for packages when available. I just did a "port upgrade outdated" a couple days ago and many of the installs were very fast as a binary of the current version was available for my OS.

Can't say I love the symlinks; however, I use homebrew for convenience, but in most cases it's ./configure --prefix=$HOME/local ...

This rarely fails. When it does, it's user error.

gcc and g++ are part of Xcode. That's the reason you have to install Xcode before you can use Homebrew.

1) Well, I could do I suppose. That all sounds a bit complicated however.

2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to.

3) You are right, it looks like gcc and gdb have both been taken out of homebrew, I assume because they didn't work. They were there previously.

Certainly I find homebrew very useful. Just now I noticed the one thing I used in fink in now in homebrew, so have removed fink which should also hopefully slove problems.

However, as time goes by, I find the OSX is getting slowly worse. In the days of OS X 10.1, the various command line tools were in sync between linux and mac os x, and now that is certainly not true, and I find the linux set more useful, especially in a default state.

Which is why the alias solution is nice, as it will only impact the interactive shell, not the scripts.

I'm curious, what are some of the pains you've had with MacPorts? I've been using it for about 8 months with no real issues, but then again I'm not a C/C++/native developer.

I've had it fail to install packages for me before, forcing me to grab them from source, modify the source with patches, and compile by hand.

I've been using Homebrew for about a year and haven't ever had an issue like that.

Reply on news.ycombinator.com