brew upgrade should download new version first

[caarlos0]

A detailed description of the proposed feature

When upgrading a bottle, first download the new version, then remove the old one and, finally, install the new.

The motivation for the feature

When upgrading things, the thing being upgraded will be unavailable for some time, since its first removed and then the download starts.

I regularly run brew upgrade and keep working since it takes some time... and often what I'm using (e.g. go) becomes unavailable during the process.

This can also lead to a "broken environment" if the user looses internet connection during the download.

How the feature would be relevant to at least 90% of Homebrew users

Probably the more common use case is being able to use the software being upgraded while its being upgraded...

It is also how other macOS apps works: the "updater" downloads the new version while you're using the currently installed one.

So I think the relevance is in "working as most users would expect" (or maybe its just me 😂).

What alternatives to the feature have been considered

If you keep the machine up all the time, maybe a cron job to do it at 4AM or something... not many ideas though 🤔

---

Thanks for Homebrew BTW, saved me TONS of time of the years! 🙏

[MikeMcQuaid]

Thanks for the kind words. This is a good idea we should consider. In the short-term you can achieve a similar result with brew fetch $(brew outdated) && brew upgrade.

[LewisErick]

I'll attempt to solve this issue. 😀

[LewisErick]

While looking into the upgrade.rb (line 184) code I stumbled upon this:

# first we unlink the currently active keg for this formula otherwise it is
# possible for the existing build to interfere with the build we are about to
# do! Seriously, it happens!

How does the brew fetch $(brew outdated) @MikeMcQuaid you suggested avoids this behavior?

[MikeMcQuaid]

@LewisErick I don't understand the question really. It doesn't need to do any linking/unlinking because it's just pre-downloading files. Anything else I can help with?

[timorunge]

Another idea is to also make downloads asynchronously from the installation / upgrade process.

Especially if packages have dependencies they will be downloaded and installed synchronously while at least the downloading part can be handled asynchronously. That will speed the installation / upgrade process up quite a bit.

[MikeMcQuaid]

@timorunge That's going to add a lot of complexity and require multithreading. It's a possible improvement but we don't accept/merge that for a first pass.

[ketanbhatt]

Is anyone working on it? I would like to contribute :)
@MikeMcQuaid

[MikeMcQuaid]

Feel free to open a PR without asking.

[ketanbhatt]

Hi @MikeMcQuaid, is it possible for you to quickly approve the approach before I code it? This is what I am thinking:

1. We can make this change the default way to upgrade, or do you think we should expose an argument to the command that lets you do a normal upgrade OR download before unlinking.
2. Fetch all outdated_kegs before https://github.com/Homebrew/brew/blob/393c8dfbf1577d40478e289a66b107818e80aef3/Library/Homebrew/cmd/upgrade.rb#L187
3. Everything else will get handled after that automatically.

[MikeMcQuaid]

@ketanbhatt Yes. You'll need to fetch them all but also their resources.

[jvanderen1]

As a quick solution in the source code, could you simply call pour, then outdated_kegs.each(&:unlink), finally install? Some code may have to change within install, but seems straightforward.

[MikeMcQuaid]

@jvanderen1 I don't really understand how that relates?

[jvanderen1]

pour looks like a method used to download a formula first. Isn't the goal to download the new formula, uninstall the old formula, then install the new formula?

[MikeMcQuaid]

@jvanderen1 pour is used to install binary packages not install them. In formula_instaler.rb downloader.fetch (which ends up in download_strategy.rb) is what downloads packages.

[Lord-V15]

Hi @MikeMcQuaid, is it possible for you to quickly approve the approach before I code it? This is what I am thinking:

1. We can make this change the default way to upgrade, or do you think we should expose an argument to the command that lets you do a normal upgrade OR download before unlinking.
2. Fetch all outdated_kegs before https://github.com/Homebrew/brew/blob/393c8dfbf1577d40478e289a66b107818e80aef3/Library/Homebrew/cmd/upgrade.rb#L187
3. Everything else will get handled after that automatically.

@MikeMcQuaid I was wondering if this approach was ever coded upon. If so, why could it not solve the issue? If not the case, should I go ahead and try to put some code into action?

[MikeMcQuaid]

1. We can make this change the default way to upgrade

Yup.

2. Fetch all outdated_kegs before

Yep. Will need to fetch resources too.

I was wondering if this approach was ever coded upon.

No.

If not the case, should I go ahead and try to put some code into action?

Please!

[MichelleNguy]

I have a pull request for this here:

https://github.com/Homebrew/brew/pull/7124

[Lord-V15]

I have a pull request for this here:

7124

I read your upgrade.rb file in the cmd folder and saw that you had added a change at line
_196_ with the code being fi.prefetch.
Did you add this prefetch functionality or was it already available for use?

[MichelleNguy]

I have a pull request for this here:

7124

I read your upgrade.rb file in the cmd folder and saw that you had added a change at line
_196_ with the code being fi.prefetch.
Did you add this prefetch functionality or was it already available for use?

Hi, @Lord-V15. #prefetch is an instance method I defined. It calls two other instance methods within it and also assigns true to a new instance variable called @prefetched. @prefetched is checked later when #install is called, and if it evaluates true, there will not be another fetch.

fetch_bottle is also a new instance method I defined, which extracted a portion of #pour. The other method #compute_dependencies was already defined prior to me making any changes.