8 ms·

I am sincerely curious when I ask this, please don't see it as flame bait-- what/who uses Macports still instead of Homebrew (or Nix)? Is it for legacy systems

I am sincerely curious when I ask this, please don't see it as flame bait-- what/who uses Macports still instead of Homebrew (or Nix)? Is it for legacy systems? Or unusual requirements? Habit? Edit for reasoning: I'm curious because who knows-- maybe I'm missing something really cool or jumped ship to Homebrew years ago too hastily? Edit #2: Just wanted to say thanks to the folks who have replied below! I'm definitely a bit more curious about macports again.

jordigh 10y ago
GNU Octave packages are still well maintained on Macports (and Fink!) and we have several enthusiastic users. I wish we could get Octave to our users without any CLI shenanigans, but it's proven very difficult to build an app bundle. We finally have one, but it's not relocatable. http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_OS_X_Bundle http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_O...
- wodenokoto 10y ago
  in my experience the bundle works great, and I'm very happy that I don't have to use home-brew.
LeoPanthera 10y ago
MacPorts is useful on multi-user systems. It installs as root, so any user of the system can access installed packages, but only admins can modify them. I'm sure Homebrew could probably be set up this way, but the defaults are a powerful thing.
- rubyn00bie 10y ago
  That's a mighty good reason to use Macports! I'll have to keep that in mind. You said you could probably configure Homebrew in a similar way, but... can you now-a-days configure macports to install without root for user local packages?* * Pardon me for the potential ignorance of this question being unreasonable or lazy.
  - LeoPanthera 10y ago
    As far as I know this has always been possible. A random Google finds this. https://coderwall.com/p/njpsxg/building-macports-without-root-anywhere https://coderwall.com/p/njpsxg/building-macports-without-roo...
bdarnell 10y ago
I still use macports, although it's mainly out of habit and I'll probably switch to brew on my next mac (I've also been trying out nix, and while I really like the idea, package availability and freshness hasn't been as good as macports or brew. Nix hasn't picked up go 1.7, for example). My main concrete reason to prefer macports is that it has separate packages for every version of python so I can have them all installed at once for testing. I also like a lot of macports' technical decisions, like the fact that my regular user doesn't have write access to the installation directory. And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore.
- rubyn00bie 10y ago
  > And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore That's really awesome. > ... has separate packages for every version of python so I can have them all installed at once for testing Are the package versions themselves configured to be installed side by side? Or are you using multiple copies of macports[1]? [1] https://guide.macports.org/#installing.macports.source.multiple https://guide.macports.org/#installing.macports.source.multi...
  - riffraff 10y ago
    they work side by side, you can just call "python27" vs "python34" and the same happens for related tools (pip, pep8 etc). The un-suffixed version ("python") refers to a default that can be switched with a single command affecting all related tools. It's great. This is not python specific either, it also works with perl, ruby, etc
    - asf8sdf8 10y ago
      now this is a pointless feature. time to get familiar with https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv
      - bdarnell 10y ago
profmonocle 10y ago
For me it's just habit since I've been using MacPorts for ages. I know of Homebrew, but since MacPorts has always worked perfectly for me I've never really been motivated to look into it.
thomnific 10y ago
I still use MacPorts and I am quite happy with it -- although I've tried to switch away a couple of times, I can't bring myself to uninstall a piece of software that's worked so reliably and faithfully for me over the years. Maybe it's just that Homebrew turned me off right away. Back in the bad old days, when the Python 2/3 split was more serious than it is now, I had a heck of a time trying to get pandas and scipy running with Homebrew. I haven't given it a try lately so perhaps things are better now. (I am probably also the kind of person where all the hectoring the Homebrew docs would do about installing to /usr/local eventually got on my nerves ... ) That being said, I don't use MacPorts versions of things like TeX or Ruby (I prefer MacTeX and plain old rvm).
- rsync 10y ago
  I use macports but I am not happy about having to install full blown XCode in order to install macports in order to install (insert trivial, minor package here). Has this changed ? I am basing this on my experience of both Snow Leopard and Mavericks ... and in those cases, I had to download and install XCode. Further, this is (I suppose) more a criticism of OSX and how it does not include basic tools ...
  - Aloha 10y ago
    I don't consider installing Xcode to be an unreasonable thing to do to - consider that 70+% of the people who buy a mac have no need for the compilers or system libraries. So it doesn't seem unreasonable to me - I mean, my debian box doesn't come with any of the devtools installed - and its a couple gigs of software to install.
    - izacus 10y ago
      10,5GB for latest Xcode which is kinda far from a trivial download size or space requirement.
      - anon1385 10y ago
        xcode-select --install is more like 130mb, not 10gb. http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/ http://osxdaily.com/2014/02/12/install-command-line-tools-ma...
ketralnis 10y ago
I use it because I like it. It's organised in a way that makes sense to me and I prefer it to homebrew
amock 10y ago
I tried Homebrew and had lots of trouble with it. I like that MacPorts is isolated so that I don't need to worry about bad interactions with the Apple compilers and libraries.
peatfreak 10y ago
I still use MacPorts because it's actually a proper package management system. Homebrew is not, and its limitations started to show a long time ago. The obnoxious assertion that Homebrew should take complete control of /usr/local AND be able to install in there as an unprivileged user is utterly ridiculous. It's just some nonsense that the author cooked up in his own head, contradicting a long history of convention regarding the use of /usr/local. The maintainers of packages are supposed to port their software to the relevant platform, that's their job, and yes sometimes this takes some work, whereas Homebrew seems to assume that ./configure; make; make install should flawlessly work out of the box for pretty much anything (this is not true). The fact that they actively discourage even trying to install outside of /usr/local is simply laziness (and not in a good way). This is a foolish and naive approach, and pursuing this idealistic, reductive approach for "simplicitly" breaks down very, very quickly. MacPorts is a well behaved, self-contained system, and a well designed one at that. Homebrew just dumps everything into a system directory that it really shouldn't have exclusive rights to in the first place (/usr/local). Moreover, there is nothing wrong with installing extra compilers, libraries, etc, under /opt/local and having them run alongside the system libraries. Lots of systems have provisions for doing something like this. Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Homebrew's documentation is terrible. Its terminology is facile and stupid in the way it analogizes everything with beer.
- pbiggar 10y ago
  > "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid". I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.
jakobegger 10y ago
A bunch of software I need just isn't available from brew.
- kkylin 10y ago
  Ditto! I also find I tend to prefer the way macports is organized.
riffraff 10y ago
I switched because most of my team uses brew, but I was happy with macports, it has a sane UI and I liked the way build options could be specified (i.e. "+python +png") The only problem I had was that some stuff requiring compilation _outside_ of macports have builds that won't work naturally (e.g. phashion gem). This is usually solveable and rare, but annoying. OTOH I've seen similar issues with brew too (i.e. need to change openssl from system version to compiled version and recompile stuff)
mulmen 10y ago
I never used it because I didn't want it to spray binaries all over a system directory. Macports is completely self-contained which I consider to be a much better design decision and less likely to cause me problems. To turn your question around, who uses Homebrew instead of Macports?
rbanffy 10y ago
I use MacPorts on my personal Mac because the whole system "feels" higher quality. When I install, say, FontForge, I get a usable font editor (that requires X) on my Mac. When I do so with Homebrew, I get a crippled command-line utility. It's predictable and boring, which is how I like my infrastructure.
krylon 10y ago
TL;DR - habit. Long answer: When I got myself a Mac (October 2013), I looked for a way to install software, and I was given the advice "use MacPorts or Homebrew, either is fine". So I briefly looked at both and for some reason stuck with MacPorts. I have not had any trouble with it, so I never had a reason so reconsider. I think the main reason I preferred MacPorts back then was that it creates its own folder hierarchy for installed software (/opt/local), while Homebrew defaulted to /usr/local. I sometimes will install stuff straight from source, which typically ends up in /usr/local, and not having anything else live there made it easier for me to keep track.
Mordak 10y ago
I use macports, but I had never switched away in the first place. My short list of reasons include macports keeping everything tucked neatly away under /opt by default, which means I can blow it away without having to worry about breaking anything else; it manages its own dependencies, so things don't break when system libraries change; and it does binary installs by default and checks shared libraries for breakage when things get upgraded. Generally I find it Just Works, so why change? As a bit of history, when homebrew first landed, it existed because the author wanted to pass optimization flags to his builds [0], and found the macports build system too complex for this purpose. Homebrew's real strength is the relative transparency of the build system (it is more obvious what will happen when a build launches), which is really a reflection of this initial complaint about macports. At the time, I didn't care about optimization flags and didn't otherwise get a good vibe from the rest of the project, so stuck with macports for the reasons I listed above (less the binary installs, which didn't exist yet). Since then, I've been a bit surprised at how much Homebrew has taken off, but macports has continued to improve as well and I am still very happy with it. [0] https://news.ycombinator.com/item?id=1198037 https://news.ycombinator.com/item?id=1198037
eddieh 10y ago
I've used MacPorts since it was DarwinPorts. This isn't out of habit, I've tried Fink, Homebrew, Nix, and Pkgsrc. All of them can't hold a candle to MacPorts. I have a super easy way to evaluate package managers, so I don't waste my time: can it install useable up to date versions of GNU Emacs (NS variant), TexLive, and Xorg Server, without hassle. Fink is dead, so we can skip it. Emacs was never up to date on Fink anyway, so I quite using it early on. Homebrew does not package texlive and has a pathetic error it prints out when you try 'brew install texlive' — this is why I refer to it as a toy package manager. Nix, failed all of the packages and was crazy slow. Xorg installed, but crashed on launch. Pkgsrc is the only one that comes close. I couldn't figure out how to install the NS variant on GNU Emacs, but everything else installed (including CLI emacs) and worked. The caveat is that all the packages had really strange names. MacPorts wins here because the packages are name as you would expect: emacs-app, texlive, xorg-server. MacPorts could make it easier to package software. Hopefully they're working on this. I would jump ship to Pkgsrc if it had better organizations and included macOS variants of packages.

jordigh 10y ago

GNU Octave packages are still well maintained on Macports (and Fink!) and we have several enthusiastic users. I wish we could get Octave to our users without any CLI shenanigans, but it's proven very difficult to build an app bundle. We finally have one, but it's not relocatable. http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_OS_X_Bundle http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_O...

wodenokoto 10y ago
in my experience the bundle works great, and I'm very happy that I don't have to use home-brew.

LeoPanthera 10y ago

MacPorts is useful on multi-user systems. It installs as root, so any user of the system can access installed packages, but only admins can modify them. I'm sure Homebrew could probably be set up this way, but the defaults are a powerful thing.

rubyn00bie 10y ago
That's a mighty good reason to use Macports! I'll have to keep that in mind. You said you could probably configure Homebrew in a similar way, but... can you now-a-days configure macports to install without root for user local packages?* * Pardon me for the potential ignorance of this question being unreasonable or lazy.
- LeoPanthera 10y ago
  As far as I know this has always been possible. A random Google finds this. https://coderwall.com/p/njpsxg/building-macports-without-root-anywhere https://coderwall.com/p/njpsxg/building-macports-without-roo...

bdarnell 10y ago

I still use macports, although it's mainly out of habit and I'll probably switch to brew on my next mac (I've also been trying out nix, and while I really like the idea, package availability and freshness hasn't been as good as macports or brew. Nix hasn't picked up go 1.7, for example). My main concrete reason to prefer macports is that it has separate packages for every version of python so I can have them all installed at once for testing. I also like a lot of macports' technical decisions, like the fact that my regular user doesn't have write access to the installation directory. And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore.

rubyn00bie 10y ago
> And macports has binary distributions now so the awful rebuild-the-world updates aren't as much of a problem anymore That's really awesome. > ... has separate packages for every version of python so I can have them all installed at once for testing Are the package versions themselves configured to be installed side by side? Or are you using multiple copies of macports[1]? [1] https://guide.macports.org/#installing.macports.source.multiple https://guide.macports.org/#installing.macports.source.multi...
- riffraff 10y ago
  they work side by side, you can just call "python27" vs "python34" and the same happens for related tools (pip, pep8 etc). The un-suffixed version ("python") refers to a default that can be switched with a single command affecting all related tools. It's great. This is not python specific either, it also works with perl, ruby, etc
  - asf8sdf8 10y ago
    now this is a pointless feature. time to get familiar with https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv
    - bdarnell 10y ago

profmonocle 10y ago

For me it's just habit since I've been using MacPorts for ages. I know of Homebrew, but since MacPorts has always worked perfectly for me I've never really been motivated to look into it.

thomnific 10y ago

I still use MacPorts and I am quite happy with it -- although I've tried to switch away a couple of times, I can't bring myself to uninstall a piece of software that's worked so reliably and faithfully for me over the years. Maybe it's just that Homebrew turned me off right away. Back in the bad old days, when the Python 2/3 split was more serious than it is now, I had a heck of a time trying to get pandas and scipy running with Homebrew. I haven't given it a try lately so perhaps things are better now. (I am probably also the kind of person where all the hectoring the Homebrew docs would do about installing to /usr/local eventually got on my nerves ... ) That being said, I don't use MacPorts versions of things like TeX or Ruby (I prefer MacTeX and plain old rvm).

rsync 10y ago
I use macports but I am not happy about having to install full blown XCode in order to install macports in order to install (insert trivial, minor package here). Has this changed ? I am basing this on my experience of both Snow Leopard and Mavericks ... and in those cases, I had to download and install XCode. Further, this is (I suppose) more a criticism of OSX and how it does not include basic tools ...
- Aloha 10y ago
  I don't consider installing Xcode to be an unreasonable thing to do to - consider that 70+% of the people who buy a mac have no need for the compilers or system libraries. So it doesn't seem unreasonable to me - I mean, my debian box doesn't come with any of the devtools installed - and its a couple gigs of software to install.
  - izacus 10y ago
    10,5GB for latest Xcode which is kinda far from a trivial download size or space requirement.
    - anon1385 10y ago
      xcode-select --install is more like 130mb, not 10gb. http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/ http://osxdaily.com/2014/02/12/install-command-line-tools-ma...

ketralnis 10y ago

I use it because I like it. It's organised in a way that makes sense to me and I prefer it to homebrew

amock 10y ago

I tried Homebrew and had lots of trouble with it. I like that MacPorts is isolated so that I don't need to worry about bad interactions with the Apple compilers and libraries.

peatfreak 10y ago

I still use MacPorts because it's actually a proper package management system. Homebrew is not, and its limitations started to show a long time ago. The obnoxious assertion that Homebrew should take complete control of /usr/local AND be able to install in there as an unprivileged user is utterly ridiculous. It's just some nonsense that the author cooked up in his own head, contradicting a long history of convention regarding the use of /usr/local. The maintainers of packages are supposed to port their software to the relevant platform, that's their job, and yes sometimes this takes some work, whereas Homebrew seems to assume that ./configure; make; make install should flawlessly work out of the box for pretty much anything (this is not true). The fact that they actively discourage even trying to install outside of /usr/local is simply laziness (and not in a good way). This is a foolish and naive approach, and pursuing this idealistic, reductive approach for "simplicitly" breaks down very, very quickly. MacPorts is a well behaved, self-contained system, and a well designed one at that. Homebrew just dumps everything into a system directory that it really shouldn't have exclusive rights to in the first place (/usr/local). Moreover, there is nothing wrong with installing extra compilers, libraries, etc, under /opt/local and having them run alongside the system libraries. Lots of systems have provisions for doing something like this. Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Homebrew's documentation is terrible. Its terminology is facile and stupid in the way it analogizes everything with beer.

pbiggar 10y ago
> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid". I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.

jakobegger 10y ago

A bunch of software I need just isn't available from brew.

kkylin 10y ago
Ditto! I also find I tend to prefer the way macports is organized.

riffraff 10y ago

I switched because most of my team uses brew, but I was happy with macports, it has a sane UI and I liked the way build options could be specified (i.e. "+python +png") The only problem I had was that some stuff requiring compilation _outside_ of macports have builds that won't work naturally (e.g. phashion gem). This is usually solveable and rare, but annoying. OTOH I've seen similar issues with brew too (i.e. need to change openssl from system version to compiled version and recompile stuff)

mulmen 10y ago

I never used it because I didn't want it to spray binaries all over a system directory. Macports is completely self-contained which I consider to be a much better design decision and less likely to cause me problems. To turn your question around, who uses Homebrew instead of Macports?

rbanffy 10y ago

I use MacPorts on my personal Mac because the whole system "feels" higher quality. When I install, say, FontForge, I get a usable font editor (that requires X) on my Mac. When I do so with Homebrew, I get a crippled command-line utility. It's predictable and boring, which is how I like my infrastructure.

krylon 10y ago

TL;DR - habit. Long answer: When I got myself a Mac (October 2013), I looked for a way to install software, and I was given the advice "use MacPorts or Homebrew, either is fine". So I briefly looked at both and for some reason stuck with MacPorts. I have not had any trouble with it, so I never had a reason so reconsider. I think the main reason I preferred MacPorts back then was that it creates its own folder hierarchy for installed software (/opt/local), while Homebrew defaulted to /usr/local. I sometimes will install stuff straight from source, which typically ends up in /usr/local, and not having anything else live there made it easier for me to keep track.

Mordak 10y ago

I use macports, but I had never switched away in the first place. My short list of reasons include macports keeping everything tucked neatly away under /opt by default, which means I can blow it away without having to worry about breaking anything else; it manages its own dependencies, so things don't break when system libraries change; and it does binary installs by default and checks shared libraries for breakage when things get upgraded. Generally I find it Just Works, so why change? As a bit of history, when homebrew first landed, it existed because the author wanted to pass optimization flags to his builds [0], and found the macports build system too complex for this purpose. Homebrew's real strength is the relative transparency of the build system (it is more obvious what will happen when a build launches), which is really a reflection of this initial complaint about macports. At the time, I didn't care about optimization flags and didn't otherwise get a good vibe from the rest of the project, so stuck with macports for the reasons I listed above (less the binary installs, which didn't exist yet). Since then, I've been a bit surprised at how much Homebrew has taken off, but macports has continued to improve as well and I am still very happy with it. [0] https://news.ycombinator.com/item?id=1198037 https://news.ycombinator.com/item?id=1198037

eddieh 10y ago

I've used MacPorts since it was DarwinPorts. This isn't out of habit, I've tried Fink, Homebrew, Nix, and Pkgsrc. All of them can't hold a candle to MacPorts. I have a super easy way to evaluate package managers, so I don't waste my time: can it install useable up to date versions of GNU Emacs (NS variant), TexLive, and Xorg Server, without hassle. Fink is dead, so we can skip it. Emacs was never up to date on Fink anyway, so I quite using it early on. Homebrew does not package texlive and has a pathetic error it prints out when you try 'brew install texlive' — this is why I refer to it as a toy package manager. Nix, failed all of the packages and was crazy slow. Xorg installed, but crashed on launch. Pkgsrc is the only one that comes close. I couldn't figure out how to install the NS variant on GNU Emacs, but everything else installed (including CLI emacs) and worked. The caveat is that all the packages had really strange names. MacPorts wins here because the packages are name as you would expect: emacs-app, texlive, xorg-server. MacPorts could make it easier to package software. Hopefully they're working on this. I would jump ship to Pkgsrc if it had better organizations and included macOS variants of packages.