3 ms·

Sure, but that’s a known flaw, and it’s also not a use case I have. I already said I’m not a fan of it’s design, but feel compelled to use it because of its dom

by jolux 5y ago

Sure, but that’s a known flaw, and it’s also not a use case I have. I already said I’m not a fan of it’s design, but feel compelled to use it because of its dominance. Brew is solidly a “worse is better” proposition. I do not care nearly as much about how my package manager works as long as it has the packages I need when I need them. This is the priority for user experience.

Maursault 5y ago
I feel you, sudo port install <package> is way too complicated. btw, anything in brew can be anywhere else, like macports or nix, all it takes is a maintainer to sponsor it. But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere. It is then recommended that you never install anything else into /usr/local. But some tools will install there by default, such as BBEdit command line tools that will default to /usr/local/bin, which actually abides by the UNIX filesystem standards by doing so.
- jolux 5y ago
  > But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere. Again, since you don't seem to be reading what I'm writing: The primary reason I use Homebrew is not because I think it has a superior design for package management or because it has the absolute greatest number of packages but because I have never once encountered a dependency that was not in its registry. It always has what I need. The same is not true of MacPorts. It is immaterial to me how many MacPorts packages exist that I don't need, because it doesn't always have the ones I do need. Here's a good example that I just found randomly right now: MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/ https://ports.macports.org/port/erlang/). Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang https://formulae.brew.sh/formula/erlang). Yes, when encountering something like this, I could take the time to update the port definition. Or I could just install the version that already exists in Homebrew and get on with things. Can you understand why I would choose the latter in the absence of a need for multi-user functionality or any other real issues with brew in day-to-day usage?
  - Maursault 5y ago
    > because I have never once encountered a dependency that was not in its registry. It always has what I need. The same is not true of MacPorts. This is the primary reason for using a package manager. What you are claiming is extraordinary, that MacPorts has some number of ports that can't build because of missing dependencies. What you are claiming is MacPorts is hopelessly broken, which ironically is precisely the way I feel about Homebrew, that while using it for a handful of ports may be fine, but that it plays fast and loose with UNIX standards and ultimately breaks down. I think it is far more likely that you came across a problem either due to the state of your system, or that there was an actual defect (which is ordinary, and that likely as not had been fixed before long), and you didn't understand and didn't want to bother with it. What I suspect is that you had one single problem somewhere and incorrectly believe, for reasons beyond understanding, a fallacious and sweeping generalization that MacPorts pervasively has missing dependencies. That's what I think because your claim is borderline absurd. But if you're happy with Homebrew, more power to you. As I stated, I disagree, and personally find Homebrew not merely superfluous but broken fundamentally for it's underlying ideology, which is to ignore the standards on the systems it is targeting, and if not for it's constant desperate and ravenous marketing, and being propped up by unrelated projects, would have died years ago, but the momentum of its hype keeps it dragging its ugly mess along without actually moving forward. I could be mistaken, but that's how I see it. > Here's a good example that I just found randomly right now: MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/ https://ports.macports.org/port/erlang/). Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang https://formulae.brew.sh/formula/erlang). No this is not in the least what you were specifying. Now your newly introduced complaint is not that dependencies are missing, but that the package is not at the bleeding edge, because you need your packages at the bleeding edge in your production for unnamed reasons. You are among those that have apparently not yet been burned by applying every update the moment you see it, have not yet seen your production grind to a halt because of your itchy trigger finger. But it is inevitable if you're applying updates without consideration of the fact that the only possible reasons for applying an update to production (as opposed to development) is 1) new features that are essential to your production, 2) bug fixes that repair your production, and/or 3) security patches which are relevant to your production or system. Without consideration of these, that is, if these considerations make no difference to your production or system, you are applying updates without reason. I never let it get this far with Homebrew, so I don't have experience with rolling back updates or upgrades with it. But MacPorts takes this into consideration, and the method for doing so is well documented in the online manual and proscribed by its listserv members generously if the manual was ignored.

by jolux 5y ago

Maursault 5y ago

I feel you, sudo port install <package> is way too complicated. btw, anything in brew can be anywhere else, like macports or nix, all it takes is a maintainer to sponsor it. But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere. It is then recommended that you never install anything else into /usr/local. But some tools will install there by default, such as BBEdit command line tools that will default to /usr/local/bin, which actually abides by the UNIX filesystem standards by doing so.

jolux 5y ago
> But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere. Again, since you don't seem to be reading what I'm writing: The primary reason I use Homebrew is not because I think it has a superior design for package management or because it has the absolute greatest number of packages but because I have never once encountered a dependency that was not in its registry. It always has what I need. The same is not true of MacPorts. It is immaterial to me how many MacPorts packages exist that I don't need, because it doesn't always have the ones I do need. Here's a good example that I just found randomly right now: MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/ https://ports.macports.org/port/erlang/). Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang https://formulae.brew.sh/formula/erlang). Yes, when encountering something like this, I could take the time to update the port definition. Or I could just install the version that already exists in Homebrew and get on with things. Can you understand why I would choose the latter in the absence of a need for multi-user functionality or any other real issues with brew in day-to-day usage?
- Maursault 5y ago
  > because I have never once encountered a dependency that was not in its registry. It always has what I need. The same is not true of MacPorts. This is the primary reason for using a package manager. What you are claiming is extraordinary, that MacPorts has some number of ports that can't build because of missing dependencies. What you are claiming is MacPorts is hopelessly broken, which ironically is precisely the way I feel about Homebrew, that while using it for a handful of ports may be fine, but that it plays fast and loose with UNIX standards and ultimately breaks down. I think it is far more likely that you came across a problem either due to the state of your system, or that there was an actual defect (which is ordinary, and that likely as not had been fixed before long), and you didn't understand and didn't want to bother with it. What I suspect is that you had one single problem somewhere and incorrectly believe, for reasons beyond understanding, a fallacious and sweeping generalization that MacPorts pervasively has missing dependencies. That's what I think because your claim is borderline absurd. But if you're happy with Homebrew, more power to you. As I stated, I disagree, and personally find Homebrew not merely superfluous but broken fundamentally for it's underlying ideology, which is to ignore the standards on the systems it is targeting, and if not for it's constant desperate and ravenous marketing, and being propped up by unrelated projects, would have died years ago, but the momentum of its hype keeps it dragging its ugly mess along without actually moving forward. I could be mistaken, but that's how I see it. > Here's a good example that I just found randomly right now: MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/ https://ports.macports.org/port/erlang/). Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang https://formulae.brew.sh/formula/erlang). No this is not in the least what you were specifying. Now your newly introduced complaint is not that dependencies are missing, but that the package is not at the bleeding edge, because you need your packages at the bleeding edge in your production for unnamed reasons. You are among those that have apparently not yet been burned by applying every update the moment you see it, have not yet seen your production grind to a halt because of your itchy trigger finger. But it is inevitable if you're applying updates without consideration of the fact that the only possible reasons for applying an update to production (as opposed to development) is 1) new features that are essential to your production, 2) bug fixes that repair your production, and/or 3) security patches which are relevant to your production or system. Without consideration of these, that is, if these considerations make no difference to your production or system, you are applying updates without reason. I never let it get this far with Homebrew, so I don't have experience with rolling back updates or upgrades with it. But MacPorts takes this into consideration, and the method for doing so is well documented in the online manual and proscribed by its listserv members generously if the manual was ignored.