set HOMEBREW_MACOS_VERSION to 0 on non-HOMEBREW_MACOS machines

Why does that need to be set?

set HOMEBREW_CURL to Homebrew'd curl

Would be good to split that out the if to share some logic with the macOS curl logic as they are pretty similar.

If this PR is accepted: shall we break this script into subscripts with system-specific (Bash) functions?

What's the motivation for that?

set HOMEBREW_MACOS_VERSION to 0 on non-HOMEBREW_MACOS machines

Why does that need to be set?

I'd prefer to set HOMEBREW_MACOS_VERSION to Version::NULL.

Currently Linuxbrew sets MacOS.version to 0 so that constructs such as the following evaluate to true on Linux. This may or may not be desirable for Homebrew. What's your feeling, Mike?

depends_on "python" if MacOS.version <= :snow_leopard

Currently Linuxbrew sets MacOS.version to 0 so that constructs such as the following evaluate to true on Linux. This may or may not be desirable for Homebrew. What's your feeling, Mike?

I still think when Linuxbrew is evaluating a formula with MacOS conditional logic it's a sign that it should have been another formula. If MacOS.version is set to Version::NULL eventually: so be it. I'll accept a change like that when it's getting us very close to the point that Linuxbrew/brew goes away and Homebrew/brew supports both macOS and Linux.

Why does that need to be set?

Related Linuxbrew's PR Linuxbrew/brew@8c78009 does not tell me much. Perhaps, @sjackman could weigh in... and he just did.

Would be good to split that out the if to share some logic with the macOS curl logic as they are pretty similar.

I didn't quite get that but I can move HOMEBREW_CURL=curl under if [[ -n "$HOMEBREW_MACOS" ]] if that's what you mean.

What's the motivation for that?

The brew.sh file is getting pretty big. I think we could break it down and transform it into some sort of a meta-script to manage overall logic and then have brew.mac.sh and brew.linux.sh (or two brew.sh files under extend/os/mac and extend/os/linux) files that would define functions that brew.sh would use, e.g.

### somewhere in brew.sh

if [[ -n "$HOMEBREW_MACOS" ]]
  do_mac_stuff
else
  do_linux_stuff
fi

I didn't quite get that but I can move HOMEBREW_CURL=curl under if [[ -n "$HOMEBREW_MACOS" ]] if that's what you mean.

Sorry, I mean unconditionally set HOMEBREW_FORCE_BREWED_CURL on Linux perhaps and then extract all the curl logic above.

The brew.sh file is getting pretty big.

I don't think it's causing a problem as-is. We can think about extractions like that if and when Linuxbrew/brew goes away.

changes related to HOMEBREW_CURL have been pushed.
changes related to HOMEBREW_MACOS_VERSION have been removed.
@sjackman will work on setting MacOS.version to NULL at some himself :)

Thanks for this PR, Maxim!

Thanks @maxim-belkin!

@maxim-belkin The more I think about this the more I don't think it makes sense as a change.

• HOMEBREW_FORCE_BREWED_CURL is still documented as something users can turn on/off on Linux even although it's now on unconditionally. In general the manpage seems incorrect in many places on Linux as-is.
• How does the Homebrew curl get installed at all? Presumably there needs to be a system one already. Why can't that continue to be used by default?

Let's discuss here and hopefully we can come up with a solution that's not just a plain revert.

I'll let Shaun weigh in and describe his design goals / approaches in first person.

In the meantime, here are my 2 cents:

HOMEBREW_FORCE_BREWED_CURL is still documented as something users can turn on/off on Linux even although it's now on unconditionally. In general the manpage seems incorrect in many places on Linux as-is.

I agree we should include updates to manpages with PRs that change behavior. However, because Linux is not officially supported by Homebrew/brew, updated manpages might create confusion. So, perhaps we should wait and add a task to revisit them before announcing (if ever) support for Linux. We could use an issue to track that. Alternatively, a (not-yet-existing) team within Homebrew org could keep an eye on it.

How does the Homebrew curl get installed at all? Presumably there needs to be a system one already. Why can't that continue to be used by default?

I believe (not 100% sure though) that Linuxbrew assumes that curl is available but is only good enough to get Linuxbrew going.

The most common problem with the system curl is that its OpenSSL certificates are so old that they don't work with some websites, requiring -k, --insecure or http rather than https. We use that to bootstrap and get up to brewed curl. If brewed curl is installed, it's preferred over using the system curl with -k, --insecure or http. I believe this issue also affected older versions of macOS. Is that the case, and if so, how was it resolved for macOS?

The most common problem with the system curl is that its OpenSSL certificates are so old that they don't work with some websites, requiring -k, --insecure or http rather than https. We use that to bootstrap and get up to brewed curl. If brewed curl is installed, it's preferred over using the system curl with -k, --insecure or http. I believe this issue also affected older versions of macOS. Is that the case, and if so, how was it resolved for macOS?

Copied from my reply in #3813:

This is not the same solution, though. In this case you're saying "if there's a Homebrew curl: always use it". In the macOS case the relevant formulae have audit checks so that a modern curl can be built and then used. If there was some sort of feature check before this was enabled with curl that would be a smarter move e.g. some test to see what sorts of crypto are supported by the system curl.

On macOS if the system curl is too old, is installing a brewed curl handled automatically, or is it up to the user to brew install curl and set HOMEBREW_FORCE_BREWED_CURL?

The behaviour implemented now on Homebrew for Linux with this PR is different than what's currently implemented on Linuxbrew. On Linuxbrew it uses the brewed curl if it's available and prefers it over the host curl, but it doesn't force installation of brewed curl if it's not installed. It doesn't set HOMEBREW_FORCE_BREWED_CURL.

On macOS if the system curl is too old, is installing a brewed curl handled automatically, or is it up to the user to brew install curl and set HOMEBREW_FORCE_BREWED_CURL?

It'll install it on brew update.

The behaviour implemented now on Homebrew for Linux with this PR is different than what's currently implemented on Linuxbrew.

What do you suggest the behaviour be so Linuxbrew/Homebrew on Linux can be the same here?

Once the brewed curl is installed by brew update, is it used preferentially over the host curl when the host curl is too old?

Yes.

Great. That's all we need then. This PR can be reverted.

The current behaviour on Linuxbrew/brew is to always prefer the brewed curl over the host curl when a brewed curl is installed. We could either implement that logic here in Homebrew/brew, or revert that logic in Linuxbrew/brew, to bring the two in sync.

@sjackman The main thing that hasn't been implemented in either as far as I can see is deciding whether the host curl is too old or not. Currently the assumption in this PR seems to be it is if it's installed. I'd suggest perhaps just asking users with a too-old curl to set the relevant environment variable after installing it. Thoughts?

If we knew which version of curl is too old, I'd suggest that brew sets HOMEBREW_FORCE_BREWED_CURL=1 for the user if /usr/bin/curl is older than that. For now though I'm fine asking users with too old curl to set it manually.

If we knew which version of curl is too old, I'd suggest that brew sets HOMEBREW_FORCE_BREWED_CURL=1 for the user if /usr/bin/curl is older than that. For now though I'm fine asking users with too old curl to set it manually.

👍 changing in #3818