4 ms·

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

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

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