Hacker News Reader

Comment by rogual | Hacker News Reader

As a user, Homebrew is a great experience.

As a package maintainer, though, one thing surprised me: you can't make your package depend on a specific version -- even a major version -- of a library.

So if MyApp uses YourLib 1.0, everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors. I have no choice but to drop whatever I'm doing and make MyApp compatible with YourLib 2.0, which may even be impossible.

It's just odd because otherwise Homebrew is so well designed. It seems like a weird omission.

Edit: Some packages get around this by packaging major versions separately (qt, qt5) but most don't.

View on HN

"everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors."

Sorry, this is just not true, we hold merging YourLib 2.0 into core until all dependents are upgraded or boneyarded. Maybe you're speaking from your outdated experience with brew years ago.

Also, we do have plans to support multiple versions of libraries, see https://github.com/Homebrew/brew/issues/620 "Handle Versions Better" (although I'm not necessarily a fan of this personally). We also have an openssl@1.1 formula in core already in case you want a sneak peek of the future.

To be clear: I'm only talking about core here. If you try to compile external software against brewed libraries, of course you may run into problems, but we do have the homebrew/versions tap, and you can always host your own taps for outdated libraries.

Thanks for responding. Yeah, my package isn't in core, although it seems I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

I get that it's all a tradeoff, and it must to help keep complexity down if brew is latest-everything.

New versions stuff looks good. I'll look into the versions tap too.

> I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

In core this is true. In your own tap you can vendor your dependencies however you want.

Thanks for trying to support multiple major versions! I run into this problem all of the time with LLVM and its dependencies. I'd love to get have the latest LLVM available for my own work (which depend on the static libraries it builds), but also be able to use tools which depend on older versions of LLVM.

It's for this very reason that I'm still one of those old-school guys who still uses MacPorts. I was horrified to see this, and in my brief time using it, it actually caused me real problems, so I went back.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google.

[1] https://news.ycombinator.com/item?id=11566720

[2] https://github.com/Homebrew/brew/issues/142

Wow. Thanks for bringing this to my attention. I recently got a new mac and I decided to give brew a spin as my package manager. I was unimpressed with many aspects of the experience- for example, getting weird snarky messages and incorrect advice when I attempted to install texlive- but this seals it.

Back to Macports it is. I'll be sure to tell others about this.

Been using Brew for as long as i can remember. Most of the message usually require a `brew doctor` or `brew update` command which completely fixes the issue. And i cant even remember the last time i had to do that..

When they brought in brew cask i was completely blown away and i use brew exclusively for installing almost everything on my mac.

I tried macports at first, but bailed out of that after i shot myself in the foot inside the hour. Switched to brew and have never looked back since.

i must be the only person on earth that can't get brew to work right.

every so often i'll try to install something with brew, and it just won't work. the last thing i'm trying to do on planet earth is spend 30 minutes debugging a packager on my workstation (as opposed to on servers, where i do this literally all day long), so i just don't bother.

I have never had a problem with homebrew. I think some people like one or the other better as a preference though.

Last time I used Macports, the installation procedure took about six hours of compiling all packages from source (granted, that was an Atom processor). Does it support binary packages now?

Yes.

Yes, official binary archives are available since MacPorts 2.0 in 2011. Due to restrictions by the various software licenses not all are distributable, though.

> following the Google Analytics debacle

I didn't even realize Homebrew was sending my info to Google Analytics :(. I am a huge fan of Homebrew, but they really should make this opt-in vs automatic by default.

Edit: To opt out (the second line is just for confirmation):

    $ brew analytics off
    $ brew analytics

Why would anoyone deliberately bother writing google analytics code in homebrew is beyond me. It should be optin or someone who is sufficiently pissed off could fork it and remove the offending code.

The devs' justification was that if it was opt-in, most people wouldn't do it. They thought it better to turn it on and force users to go manually disable it.

I disagreed in the GitHub issue about this. Debian's Popcorn (package popularity analytics) is opt-in - a choice on install that defaults to "off". That would be the perfect solution. Ultimately those who agreed with me were told that the decision was made and there would be no further discussion - the issue was closed and locked.

was it that hard to just, you know, type "brew analytics off"? Or was there more to that decision?

I've found that a lot of people here in HN and Reddit are really passionate about not being tracked, so even if it was as easy as one command, the fact that Homebrew did it at all is enough to make some people not want to use it.

Nothing wrong with that viewpoint, but I just disabled it and moved on to enjoying pretty good software.

It has nothing to do with how easy or hard it is to disable. The problem is that it doesn't ask first, or even tell you what it's doing. OK, now that I know about it, I can turn it off, but how do I know they won't do something similarly ugly in a future version?

We do tell you about it before we start recording any analytics.

You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.

Privacy violations and user tracking should always be opt-in not opt-out. If nobody opts in, one should rationalize why users may not want to be tracked or have their privacy violated and question whether making it opt-out is a good decision and respectful of their users.

Most people, myself included, never even heard about this before this point, because it's never mentioned as part of the installation or usage process and is opt-out—if you know it exists and that you might want to opt out in the first place.

Actually, at the time I left for MacPorts, "brew analytics off" wasn't an option. Analytics was turned on without warning and without any obvious way to turn it off. They added an environment variable but still left it opt-out (on by default). I disagreed but users who complained were told that the decision was made and no further discussion would be allowed. [1]

> If you feel that way: please use another package manager.

I didn't like how it was handled. I think any sort of analytics, especially by third party companies with real capabilities for correlation and de-anonymisation should be strictly opt-in (off by default).

Opt-in doesn't really hurt users who don't care about privacy and security. Opt-out does hurt users who care about those things. Many organisations have security policies that discourage using software that "calls home". I'd trust the software much more if it didn't have that functionality at all.

The developer's justification was that if it was off by default, no-one would turn it on. I think that speaks volumes about how users feel about analytics these days. Some users suggested a Debian Popcorn style dialog ("We'd love it if you could help us gather some information about package usage, etc etc. Would you like to participate [y/N]", off by default but a question on first run asking the user if they'd like to help). We were told "no".

Overall, I thought it was a bad idea and the situation was handled poorly. For something as integral as a package manager I expect more.

[1] https://github.com/Homebrew/brew/issues/142#issuecomment-214...

I almost went the other way (from ports to brew) because of the complex manual procedure required to fix ports when you upgrade the OS:

https://trac.macports.org/wiki/Migration

After going through the migration, it isn't that bad, but it was surprising (horrifying?) to me that ports was completely broken after an OS upgrade.

MacPorts dev here. Problems can arise when some ports have local patches for specific versions of macOS. This might work at first, but could lead to build failures or other problems later. Some ports also hardcode the OS version into their binaries. The simple way to prevent this kind of stuff is to rebuild all ports for the new platform.

Probably there would be room for improvement, but there is only little interest by contributors. This only happens once a year and after everybody went through it, they quickly loose interest in contributing anything better for the migration process.

This is a valid concern and it's something we're actively working on: https://github.com/Homebrew/brew/issues/620

An argument for this approach is that it keeps the ecosystem healthy. Instead of a lot upper version bounds to keep track of and conflicting dependencies, broken dependents are fixed upstream if they don't build. As I understand it nixpkgs, in general, works this way.

As someone who maintain a ROS installation scheme for Mac based on homebrew (https://github.com/mikepurvis/ros-install-osx), this is a constant source of frustration.

Even a fairly vanilla ROS installation has a deep dependency tree— there are any of several dozen major packages which can at any moment release a new major version and break us.

If you rely heavily on Homebrew in this way you should instead vendor all the formulae you depend on so that updates do not happen without your manual intervention.

Exactly. That's how I managed an app (basically a port of lots of stuff from Linux) for macOS years ago. I depended upon MacPorts as my build system, lots of patching to match our in-house build on Linux... but wrapped an entire Python etc universe inside the app.

That's basically what is done, on a piecemeal basis as things break, but it would be untenable to do it for the dozens of system dependencies, especially when I don't have the resources to set up a whole parallel bottling infrastructure.

In the end, most ROS Mac users still choose an Ubuntu, Debian, or Fedora VM— having a stable set of underlying packages is worth the tradeoff in convenience and performance.

As I've mentioned before: I'm afraid that's a problem for ROS to solve, not Homebrew. We make these options available to you regardless of whether you choose them. Sorry!

Yup, totally understand. I'm looking into Nix and other solutions to see if there might be something else that's a better fit for this use case than Homebrew.

Few years back when I used OS X I used Homebrew, but also used pkgsrc. It had a few packages that I wanted that Homebrew did not offer. From what I remember it was not a smooth ride, but good enough.

How does Homebrew compare to pkgsrc these days?

Reply on news.ycombinator.com