Avoid lengthy brew auto-update when running brew install?

I use homebrew infrequently, possibly once every few months. Often I run into a situation where I need to install a command line utility to accomplish some given task.

However, when running brew install <package>, it appears the default behavior to first auto-update homebrew, then install the package.

In my most recent experience, running brew install led to both installing a new version of homebrew as well as downloading and installing a new version of portable ruby (2.6.3). The entire process took over 5 minutes for a <100KB binary utility (ncdu, in this case). A subsequent run of brew reinstall took 4 seconds for the same utility.

So my question is, are we forced to auto-update homebrew by design? Can we opt-out of automatic updates to avoid a lengthy install process?

1 Like

Would you be adverse to setting up launchd to automatically update brew every day or so? That’s what I’ve done so I’m Would you be adverse to setting up launchd to automatically update brew every day or so? That’s what I’ve done so I’m never too far behind “current”.

I have a shell script which runs:

brew update
brew upgrade
brew cleanup
brew doctor

And if brew doctor produces unexpected ¹ results, it will alert me to the fact. Otherwise, the whole thing happens completely behind the scenes.

¹ by “unexpected” I don’t just mean that brew doctor is not “Your system is ready to brew.” I have a couple Macs which have other things installed in /usr/local/ which gives a “warning” in brew doctor. For example, my MacBook Air says:

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don’t worry or file an issue; just ignore this. Thanks!

Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn’t put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected dylibs:
  /usr/local/lib/libwkhtmltox.0.12.5.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn’t put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
  /usr/local/include/wkhtmltox/image.h
  /usr/local/include/wkhtmltox/pdf.h

but since I know that, the script only alerts me if brew doctor says something else.

Anyway, I’d be happy to share my setup if it would be useful. You wouldn’t have to have it run daily, even. It could be every couple of days, or even weekly.

Yes. Chances are due to Xcode/macOS updates installing old versions won’t work. ~5 minutes every couple of months does not seem like a large amount of time to wait.

Yes, man brew explains how to do this. I would not advise it and we will not fix any issues you encounter with it set.

Hi all, thanks for the replies.

Would you be adverse […] to automatically update brew every day or so?

While I applaud the pragmatic nature of this approach, I would prefer to supervise the process so I can be aware of what was updated.

Chances are due to Xcode/macOS updates installing old versions won’t work.

Totally understandable. I’m not questioning the motivations that led to this design, just the implementation.

~5 minutes every couple of months does not seem like a large amount of time to wait.

In the grand scheme of things, you’re right about this.

Yes, man brew explains how to do this.

Thanks for pointing this out. I found the following:

ENVIRONMENT
   Note  that environment variables must have a value set to be detected. For example, run export HOMEBREW_NO_INSECURE_REDIRECT=1
   rather than just export HOMEBREW_NO_INSECURE_REDIRECT.

  [...]

   HOMEBREW_NO_AUTO_UPDATE
          If set, Homebrew will not auto-update before running brew install, brew upgrade or brew tap.

I would not advise it and we will not fix any issues you encounter with it set.

I understand that I’m on my own with this path, I accept that risk.

If I were to restate my original point, it would be that auto-updating is not a behavior I am expecting when trying to install a package. For example: In other package managers I’m familiar with such as yum and apt, updating the package manager and package lists are separate, manual and hopefully conscious actions. When running brew install, I am not expecting that I am also running other update processes along with that command.

In my opinion, the brew install command should go as far as checking and making the user aware that there are updates available. Here’s an example direct from the Bundler gem often used in Ruby (including by Homebrew!)

Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.

The user is made aware they are running out-of-date software and it is up to them to determine the best course of action for their needs. Isn’t user control the end goal after all? :slight_smile:

For example: In other package managers I’m familiar with such as yum and apt , updating the package manager and package lists are separate, manual and hopefully conscious actions.

Both of these don’t have an evergreen approach like homebrew has. I’m pretty sure something like arch’s pacman will actually upgrade.

The user is made aware they are running out-of-date software and it is up to them to determine the best course of action for their needs. Isn’t user control the end goal after all?

I’d say the end goal is working software and just like with with Apple software that requires relinquishing some control.

As do I. Just because it’s automated doesn’t mean I’m not aware of what it is doing.

I uploaded my script to https://github.com/tjluoma/updatebrew so you can see it for yourself.

It logs everything it does, and you can easily change where the log is stored if you want.

If any step fails, then the entire process is stopped.

Literally the only thing that is different is that you don’t have to sit there and babysit it while it happens.

(I’ll be happy to answer questions about the script and how to install / use it, if anyone has questions.)