brew.sh: don't set HOMEBREW_NO_INSTALL_FROM_API automatically.

[MikeMcQuaid]

My understanding from conversations with Bo98 is that this should now work fine on both older macOS versions and non-default prefixes.

Similarly, it's super confusing when this is set automatically and you can't figure out why...

[EricFromCanada]

In Installation.md, drop the "Note that this will automatically be set" paragraph as well.

[MikeMcQuaid]

@EricFromCanada good catch, done, thanks.

[MikeMcQuaid]

Pretty sure @Bo98 is out for a bit so: gonna merge this as-is for now.

[gerlero]

FWIW, this change seems to have broken a bunch of formula installs on a non-default prefix, e.g.:

==> Fetching fftw
==> Downloading https://ghcr.io/v2/homebrew/core/fftw/manifests/3.3.10_1
==> Downloading https://ghcr.io/v2/homebrew/core/fftw/blobs/sha256:bd3ae1b553913b3b627bd1af592d84da4c6a93e45dde5af4df7c393564b0f174
==> Installing dependencies for fftw: gcc, hwloc, ca-certificates, openssl@3, libevent and open-mpi
==> Installing fftw dependency: gcc
Error: An exception occurred within a child process:
  FormulaUnavailableError: No available formula with the name "/Volumes/OpenFOAM-v2306/homebrew/Library/Taps/homebrew/homebrew-core/Formula/gcc.rb".
Installing fftw has failed!

Looks like attempting to install a formula that depends on gcc or openssl@3 on a custom prefix fails with this error. Curiously, installing gcc and/or openssl@3 directly works; and doing that first appears to be a valid workaround for the above error. I have no clue on what could be causing this behavior, but a common factor between gcc and openssl@3 is that both need to be built from source when using non-default prefixes...

Setting HOMEBREW_NO_INSTALL_FROM_API=1 again fixes all problems.

[carlocab]

Reverting in #15768.

[Bo98]

Ah forgot we were still doing this on older macOS.

The breakage however wasn't expected - I'm guessing there's an edge case in dependency installs as that's the one area that probably hasn't been fully tested. Will take a look as soon as I can.

[MikeMcQuaid]

Ah forgot we were still doing this on older macOS.

Older macOS and non-default prefixes too.

[gerlero]

Thanks for the quick response and revert. I can confirm that everything went back to working after #15768 was merged.

(This issue notwithstanding, eventually having API installs enabled on non-default prefixes would of course be great).

[osalbahr]

(This issue notwithstanding, eventually having API installs enabled on non-default prefixes would of course be great).

I agree. Do we know why the API installs don’t work on non-default prefixes? Homebrew technically doesn’t support having a non-default prefix, but I’m interested to look into it to see if a non-intrusive fix is possible.

[gerlero]

@osalbahr A fix is being proposed at #15778