4 ms·

I've been using Homebrew for a few years now, but I've gotta admit that recently I've been intrigued by MacPorts. Can anyone that has tried both extensively sha

I've been using Homebrew for a few years now, but I've gotta admit that recently I've been intrigued by MacPorts. Can anyone that has tried both extensively share their thoughts, and possibly explain why they're using one or the other? I read up a few comments online from having googled around, but I'd love something more recent. One of my complaints with Homebrew (and most system package managers) is that it treats all dependencies as equal. If I install X, which depends on Y and Z... I'd expect Y and Z to be removed when uninstalling X. If anyone else is frustrated by this, I'd suggest checking out homebrew-bundle [0]. The idea is simple: you create a Brewfile and you use that to track dependencies. Instead of installing stuff from the CLI, you add entries to your Brewfile and run "brew bundle --global". Sadly it won't do any automatic cleanups, so you have to run "brew bundle cleanup --global" to get a list of extraneous packages and remove em manually. Another obvious benefit to using a text file is that you can annotate it with reminders. "What did I install this foobar tool for?" I think migrating towards a shell environment which gets configured using idempotent scripts can help reduce bugs and lower the barrier of entry to people less familiar with the ecosystem, as well as make it easier to get your own system up and running. In the last few weeks I started toying around with nix [1], which seems to promise that... Although I'm still finding my way through their ecosystem. I'd like to think I'm a fairly pragmatic user, so I'm willing to accept some hacks here and there. A few days back I put up a repo [2] to show what my macOS + fish shell setup looks like. It won't track configs to clean-up garbage or anything fancy like that, so if you make any change you might need to clean up manually. But it should make bootstrapping a new system a bit easier, and it encourages you to configure all universal variable definitions in a single place so you can add notes for why you're doing whatever it is you're doing. One of the biggest benefits of maintaining an idempotent fish config is that it has great performance. Since fish shell persists environment values in a single file and it lazy-loads function definitions, starting a new session happens almost instantly. [0] https://github.com/Homebrew/homebrew-bundle https://github.com/Homebrew/homebrew-bundle [1] https://nixos.org/nix/ https://nixos.org/nix/ [2] https://github.com/cesarandreu/dotfiles https://github.com/cesarandreu/dotfiles

eslaught 10y ago
I switched away from MacPorts because packages I cared about were consistently out of date. For example, the MacPorts package for Pandoc is 3 year old [1][2]. That's a cherry-picked example, of course, but was representative of my experience at the time, and appears to still be true. In contrast, the packages I've found on Homebrew have generally been up-to-date or close to it. Your milage will of course vary, and I suspect that more popular packages are probably updated much more aggressively. [1]: https://www.macports.org/ports.php?by=name&substr=pandoc https://www.macports.org/ports.php?by=name&substr=pandoc [2]: http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014 http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014
- jonhohle 10y ago
  Did you consider submitting a patch? In the past I've submitted patches and kept my own portfile in the mean time (seems quicker than replacing an entire package manager).
  - eslaught 10y ago
    Honestly, no. If I were in the same position today, I would do so. I have submitted patches to Homebrew, for example. In my defense, the Homebrew project is much more upfront about user contributions, and I think that's a big part of why they get them. It's literally right on their homepage: > It's all git and ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates. > brew edit wget # opens in $EDITOR! This does two things: (1) it demystifies the package format and makes it sound like something that's easy to get into, and (2) the presentation in general seems much more welcoming and positions the project as one which is open to contributions. In contrast, I've messed around with packaging on Debian, and my experience there was that there were much higher upfront costs to contributing, precisely because there was so much more tooling around the system. As an example of what I mean, try taking an existing Debian package (like, say, PHP), and rebuild it with different compile-time flags. It's a lot of work to figure out how to do that! I'm not in a position to say whether the ports system and MacPorts are anything like that, but I do have to wonder if (as representatives of a more traditional era of packaging) whether they suffer from some of the same burdens.

eslaught 10y ago

I switched away from MacPorts because packages I cared about were consistently out of date. For example, the MacPorts package for Pandoc is 3 year old [1][2]. That's a cherry-picked example, of course, but was representative of my experience at the time, and appears to still be true. In contrast, the packages I've found on Homebrew have generally been up-to-date or close to it. Your milage will of course vary, and I suspect that more popular packages are probably updated much more aggressively. [1]: https://www.macports.org/ports.php?by=name&substr=pandoc https://www.macports.org/ports.php?by=name&substr=pandoc [2]: http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014 http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014

jonhohle 10y ago
Did you consider submitting a patch? In the past I've submitted patches and kept my own portfile in the mean time (seems quicker than replacing an entire package manager).
- eslaught 10y ago
  Honestly, no. If I were in the same position today, I would do so. I have submitted patches to Homebrew, for example. In my defense, the Homebrew project is much more upfront about user contributions, and I think that's a big part of why they get them. It's literally right on their homepage: > It's all git and ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates. > brew edit wget # opens in $EDITOR! This does two things: (1) it demystifies the package format and makes it sound like something that's easy to get into, and (2) the presentation in general seems much more welcoming and positions the project as one which is open to contributions. In contrast, I've messed around with packaging on Debian, and my experience there was that there were much higher upfront costs to contributing, precisely because there was so much more tooling around the system. As an example of what I mean, try taking an existing Debian package (like, say, PHP), and rebuild it with different compile-time flags. It's a lot of work to figure out how to do that! I'm not in a position to say whether the ports system and MacPorts are anything like that, but I do have to wonder if (as representatives of a more traditional era of packaging) whether they suffer from some of the same burdens.