Why "/opt/homebrew" only?

[tjconcept]

In the process of installing a new M1 machine, I've come across multiple versions of the "install into /opt/homebrew" recommendation (like Homebrew/brew#7857 (comment)), but none of them say why.

I'm curious what makes that path so special, and why Homebrew is dumping the "install anywhere" feature?

I've personally always avoided installing anything into non-user directories (having Homebrew at ~/Applications/homebrew) and never noticed any issues.

[carlocab]

You can still install anywhere you want. However, a number of bottles (pre-built binary packages) will not work for you if you don't install in /opt/homebrew.

If you use a non-/opt/homebrew prefix, some of these formulae will just refuse to pour a bottle. You'll have to build those from source. Other formulae may still pour a bottle, but it's difficult to guarantee they'll work as well as if you used /opt/homebrew as your prefix.

[benjibee]

@carlocab I'm working on a PR now for the brew.sh site and I'd like to confirm a few assumptions before I edit the texts:

• This issue is dead-in-the-water, currently no plans exist to ever implement it.
• The documentation is incorrect in its language with statements like "you can place a Homebrew installation wherever you like"
• The various workarounds aren't supported and issues shouldn't be opened in Github is errors are encountered related to installing outside of the default prefixes.
• These workarounds shouldn't therefor be mentioned in the documentation, though stating they exist is acceptable.

One question I do have very much inline with @tjconcept's original question: when the switch to /opt/homebrew as a prefix was made how is this any different from allowing another custom prefix? Do you have any idea how many bottles simply hard-coded this new prefix for ARM installs or is it safe to assume that anything that works in ARM is using something akin to $(brew --prefix)?

Additionally, is there anything holding Homebrew back from asking all contributors to only use this to determine prefixes so bottles would eventually be mostly compatible with custom prefixes?

[SMillerDev]

This issue is dead-in-the-water, currently no plans exist to ever implement it.

Implement what exactly?

The documentation is incorrect in its language with statements like "you can place a Homebrew installation wherever you like"

You can, but the next line is also important "However do yourself a favour and use the installer to install to the default prefix. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing here. Pick another prefix at your peril!"

when the switch to /opt/homebrew as a prefix was made how is this any different from allowing another custom prefix?

Because the location it's compiled with determines the hardcoded prefix, which on ARM is /opt/Homebrew. Changing it would require recompiling.

Additionally, is there anything holding Homebrew back from asking all contributors to only use this to determine prefixes so bottles would eventually be mostly compatible with custom prefixes?

I'm not sure what you mean.

[benjibee]

This issue is dead-in-the-water, currently no plans exist to ever implement it.

Implement what exactly?

Implement any sort of solution in Homebrew that would enable using custom prefixes in practice, not just in theory.

The documentation is incorrect in its language with statements like "you can place a Homebrew installation wherever you like"

You can, but the next line is also important "However do yourself a favour and use the installer to install to the default prefix. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing here. Pick another prefix at your peril!"

This was in context of the previous conversation about submitting a PR updating this language to make it clearer. Saying you could do a thing when it likely won't work and the project isn't heading in a direction that's pushing for support of it can be quite confusing.

when the switch to /opt/homebrew as a prefix was made how is this any different from allowing another custom prefix?

Because the location it's compiled with determines the hardcoded prefix, which on ARM is /opt/Homebrew. Changing it would require recompiling.

I guess that answers my question. Bottles for ARM have hard-coded prefixes.

Additionally, is there anything holding Homebrew back from asking all contributors to only use this to determine prefixes so bottles would eventually be mostly compatible with custom prefixes?

I'm not sure what you mean.

I mean asking maintainers and contributors to use something akin to $(brew --prefix) to determine the prefix and avoid hard-coding it altogether.

[SMillerDev]

I mean asking maintainers and contributors to use something akin to $(brew --prefix) to determine the prefix and avoid hard-coding it altogether.

I think you might be misunderstanding where most of hardcoding happens. Generally when homebrew builds something we tell the build where to find things like configuration files before compiling. That means you can't use that binary with a non-default prefix because then it would be looking at the CI/standard prefix instead of your prefix.

The only way around that is recompiling, which takes a lot of effort and might not always work with your prefix because of assumptions in the build for example.

[tjconcept]

One year in on my M1 with a custom path and I have yet to see any issues! ☺️

If someone hardcoded a path, I'd be tempted to trash their program as garbage 😏, but it hasn't happened.