5 ms·

Still a macports user, however I used homebrew for a short period. What is the benefit here from homebrew? Compile speed?

steeleduncan 1y ago
It isn't very clear on that, but I think it is a way of automatically downloading binaries from Github releases. If so, that wouuld work well in some cases, and poorly in others
- geerlingguy 1y ago
  Part of the appeal of Homebrew (which is also a blessing and a curse from time to time) is the fact that packages are maintained, meaning people make conscious decisions when to pull in updated versions or stick with an older release, and have some logic behind all that mess. There are always tradeoffs with any packaging system, no matter how transparent/simple.
  - asdff 1y ago
    Hombrew just pulls the latest versions of everything I have installed whenever I try and install one new unrelated thing. The defaults are kind of annoying in that: " Unless $HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK is set, brew upgrade or brew reinstall will be run for outdated dependents and dependents with broken linkage, respectively. Unless $HOMEBREW_NO_INSTALL_CLEANUP is set, brew cleanup will then be run for the upgraded formulae or, every 30 days, for all formulae." However I don't think even these flags are sufficient. I think to really ensure nonbreaking behavior you have to use a brew pin command on each and every formula you have installed on the system. Really annoying defaults considering brew is a developer facing program not a consumer facing program where the tradeoff between security and functionality makes more sense. This is why I still reach for conda whenever possible. I am at least prompted before 100 things are installed.
    - acdha 1y ago
      The defaults are the correct choice for a stable system unless you’re going to make full isolated installs for every package. The packages are built and tested together so holding back some updates is a recipe for inconsistent behaviour because everyone’s system will have different versions of everything based on when they installed packages. We stopped doing that for good reasons. It’s been many years since I’ve had a problem caused by Homebrew’s design but if you like keeping things frozen like that, it sounds like you might be a better fit for Nix or working in containers where you aren’t fighting a distribution designed to stay consistently current across the entire system.
      - deleted 1y ago
        [deleted]
      - asdff 1y ago
        Yeah the happy medium I have found is to just see if the authors have submitted the package to anaconda and use that instead. Brew when that is no longer available. I will usually have one conda env per package or at the most per project. It isn't just that things "work together" but in some cases authors change how their tools work between versions and I may have stuff installed that depends on these outdated paradigms. In other words, the stuff I have built is not sure to work together with updated brew packages. I have a few scripts for example where numpy complains how I call some function will no longer merely throw a warning but actually not work at all in future versions. I can either spend my free time to rewrite the script to do it how the numpy authors now want me to do it, or I can just not do that and live on the old numpy and not be any worse for wear.
    - droelf 1y ago
      You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally. https://pixi.sh https://pixi.sh
atmosx 1y ago
I’ve been using MacPorts for over 10 years now. As far as I know, version stubbing isn’t supported—you have to upgrade regardless. Another feature I find missing is the ability to sync installations across multiple systems. For example, if I install pkg1 on system1, I’d like it to automatically be available on system2 as well.
- jonhohle 1y ago
  I think having venv like project installations would be nice as well. Let me write a Portfile for my current repo, use the system package cache if available, otherwise install locally. With clones it wouldn’t even require much extra space.

steeleduncan 1y ago

It isn't very clear on that, but I think it is a way of automatically downloading binaries from Github releases. If so, that wouuld work well in some cases, and poorly in others

geerlingguy 1y ago
Part of the appeal of Homebrew (which is also a blessing and a curse from time to time) is the fact that packages are maintained, meaning people make conscious decisions when to pull in updated versions or stick with an older release, and have some logic behind all that mess. There are always tradeoffs with any packaging system, no matter how transparent/simple.
- asdff 1y ago
  Hombrew just pulls the latest versions of everything I have installed whenever I try and install one new unrelated thing. The defaults are kind of annoying in that: " Unless $HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK is set, brew upgrade or brew reinstall will be run for outdated dependents and dependents with broken linkage, respectively. Unless $HOMEBREW_NO_INSTALL_CLEANUP is set, brew cleanup will then be run for the upgraded formulae or, every 30 days, for all formulae." However I don't think even these flags are sufficient. I think to really ensure nonbreaking behavior you have to use a brew pin command on each and every formula you have installed on the system. Really annoying defaults considering brew is a developer facing program not a consumer facing program where the tradeoff between security and functionality makes more sense. This is why I still reach for conda whenever possible. I am at least prompted before 100 things are installed.
  - acdha 1y ago
    The defaults are the correct choice for a stable system unless you’re going to make full isolated installs for every package. The packages are built and tested together so holding back some updates is a recipe for inconsistent behaviour because everyone’s system will have different versions of everything based on when they installed packages. We stopped doing that for good reasons. It’s been many years since I’ve had a problem caused by Homebrew’s design but if you like keeping things frozen like that, it sounds like you might be a better fit for Nix or working in containers where you aren’t fighting a distribution designed to stay consistently current across the entire system.
    - deleted 1y ago
      [deleted]
    - asdff 1y ago
      Yeah the happy medium I have found is to just see if the authors have submitted the package to anaconda and use that instead. Brew when that is no longer available. I will usually have one conda env per package or at the most per project. It isn't just that things "work together" but in some cases authors change how their tools work between versions and I may have stuff installed that depends on these outdated paradigms. In other words, the stuff I have built is not sure to work together with updated brew packages. I have a few scripts for example where numpy complains how I call some function will no longer merely throw a warning but actually not work at all in future versions. I can either spend my free time to rewrite the script to do it how the numpy authors now want me to do it, or I can just not do that and live on the old numpy and not be any worse for wear.
  - droelf 1y ago
    You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally. https://pixi.sh https://pixi.sh

atmosx 1y ago

I’ve been using MacPorts for over 10 years now. As far as I know, version stubbing isn’t supported—you have to upgrade regardless. Another feature I find missing is the ability to sync installations across multiple systems. For example, if I install pkg1 on system1, I’d like it to automatically be available on system2 as well.

jonhohle 1y ago
I think having venv like project installations would be nice as well. Let me write a Portfile for my current repo, use the system package cache if available, otherwise install locally. With clones it wouldn’t even require much extra space.