7 ms·

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 --

by rogual 10y ago

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.

rwl4 10y ago
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.
- davb 10y ago
  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 https://news.ycombinator.com/item?id=11566720 [2] https://github.com/Homebrew/brew/issues/142 https://github.com/Homebrew/brew/issues/142
  - RodgerTheGreat 10y ago
    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.
    - moridin007 10y ago
      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.
      - beachstartup 10y ago
        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.
    - sigzero 10y ago
      I have never had a problem with homebrew. I think some people like one or the other better as a preference though.
  - skykooler 10y ago
    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?
    - amake 10y ago
      Yes.
    - raimue 10y ago
      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.
  - tedmiston 10y ago
    > 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
  - petre 10y ago
    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.
    - davb 10y ago
      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.
  - rcarmo 10y ago
    was it that hard to just, you know, type "brew analytics off"? Or was there more to that decision?
    - sotojuan 10y ago
      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.
      - mikeash 10y ago
        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?
        mikemcquaid 10y ago
        We do tell you about it before we start recording any analytics.
        bangonkeyboard 10y ago
        You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.
    - Nadya 10y ago
      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.
    - waterphone 10y ago
- kbutler 10y ago
  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 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.
  - deleted 10y ago
    [deleted]
  - raimue 10y ago
    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.
oefrha 10y ago
"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 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.
- oefrha 10y ago
  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.
  - rogual 10y ago
    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.
    - oefrha 10y ago
      > 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.
- adrianm 10y ago
  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.
mikepurvis 10y ago
As someone who maintain a ROS installation scheme for Mac based on homebrew (https://github.com/mikepurvis/ros-install-osx 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.
- mikemcquaid 10y ago
  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.
  - watersb 10y ago
    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.
  - mikepurvis 10y ago
    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.
    - mikemcquaid 10y ago
      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!
      - mikepurvis 10y ago
hawski 10y ago
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?
mjhoy 10y ago
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.
mikemcquaid 10y ago
This is a valid concern and it's something we're actively working on: https://github.com/Homebrew/brew/issues/620 https://github.com/Homebrew/brew/issues/620

by rogual 10y ago

rwl4 10y ago

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.

davb 10y ago
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 https://news.ycombinator.com/item?id=11566720 [2] https://github.com/Homebrew/brew/issues/142 https://github.com/Homebrew/brew/issues/142
- RodgerTheGreat 10y ago
  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.
  - moridin007 10y ago
    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.
    - beachstartup 10y ago
      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.
  - sigzero 10y ago
    I have never had a problem with homebrew. I think some people like one or the other better as a preference though.
- skykooler 10y ago
  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?
  - amake 10y ago
    Yes.
  - raimue 10y ago
    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.
- tedmiston 10y ago
  > 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
- petre 10y ago
  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.
  - davb 10y ago
    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.
- rcarmo 10y ago
  was it that hard to just, you know, type "brew analytics off"? Or was there more to that decision?
  - sotojuan 10y ago
    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.
    - mikeash 10y ago
      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?
      - mikemcquaid 10y ago
        We do tell you about it before we start recording any analytics.
        bangonkeyboard 10y ago
        You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.
  - Nadya 10y ago
    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.
  - waterphone 10y ago
kbutler 10y ago
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 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.
- deleted 10y ago
  [deleted]
- raimue 10y ago
  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.

oefrha 10y ago

"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 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.

oefrha 10y ago
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.
- rogual 10y ago
  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.
  - oefrha 10y ago
    > 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.
adrianm 10y ago
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.

mikepurvis 10y ago

As someone who maintain a ROS installation scheme for Mac based on homebrew (https://github.com/mikepurvis/ros-install-osx 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.

mikemcquaid 10y ago
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.
- watersb 10y ago
  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.
- mikepurvis 10y ago
  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.
  - mikemcquaid 10y ago
    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!
    - mikepurvis 10y ago

hawski 10y ago

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?

mjhoy 10y ago

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.

mikemcquaid 10y ago

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