Is it time to default HOMEBREW_PREFIX and warnings around it?

[nemith]

TL;DR; Is it time to reconcider the fixed homebrew prefix?

Homebrew seems to be strongly worded around keeping a standard prefix for where homebrew is installed. The understanding is that some bottles are hardcoded (or perhaps require to have a standard prefix?) and it seems that changing of this prefix or installing into a custom directory is unsupported and the effort is 100% on the user.

However there seems to already be exceptions to this:

ARM macs has moved to /opt while Intel is /usr/local/opt.
Linux uses either /home/linuxbrew/.linuxbrew or /home/$USER/.linuxbrew.

Also on Linux the use of a directory in /home is bad practice and against LFS standards. There are new services like systemd-homed which is an effort to manage /home outside of a filesystem and won't work with this prefix: https://systemd.io/HOME_DIRECTORY/

Perhaps with the recent changes now is the opportunity to start fixing the reason for these static prefix definitions and do one of the two options.:

1. Allow for custom prefixes and work with fixing broken formulas
2. Change the prefix for linuxbrew to somewhere better (like /opt/homebrew/) and deal with the fixing of formulas

[SMillerDev]

However there seems to already be exceptions to this:
ARM macs has moved to /opt while Intel is /usr/local/opt.
Linux uses either /home/linuxbrew/.linuxbrew or /home/$USER/.linuxbrew.

Those are the respective standard prefixes for those platforms and get CI and fixes for them.

Also on Linux the use of a directory in /home is bad practice and against LFS standards.

But it is the primary use case for Homebrew on Linux: "I do not have root permissions but want to install newer tools" in which case any other directory will be near impossible to use.

Allow for custom prefixes and work with fixing broken formulas

It's already allowed, it's just a bad idea and you'll have to fix any issues you find by yourself.

Change the prefix for linuxbrew to somewhere better (like /opt/homebrew/) and deal with the fixing of formulas

That will break the usecase for which homebrew on Linux was created so that's unlikely to happen.

[nemith]

Those are the respective standard prefixes for those platforms and get CI and fixes for them.

I am not sure what you mean here. Standards by the platform or standards set by homebrew developers? Linux use of /home/linuxbrew/.linuxbrew seems agains the standards. I guess my point here is that the prefix have changed in the past so making it clearly definable with the install scripts would be useful.

But it is the primary use case for Homebrew on Linux: "I do not have root permissions but want to install newer tools" in which case any other directory will be near impossible to use.

The install script checks to see if sudo is available for the current user and then uses /home/linuxbrew/.linuxbrew and not $HOME/.linuxbrew. If sudo isn't available then it defaults back to the users home directory. To be honest I would be happy with an override to just install in my local home directory. But /home/linuxbrew doesn't fit either.

My use case is actually a private tap for distributing internal CLI tools to laptops. Majority is OS X with occasional Linux/WSL and homebrew seems like a good way to handle that esp with python tools and being able to lock to a python version.

It's already allowed, it's just a bad idea and you'll have to fix any issues you find by yourself.

It's allowed but intentionally made difficult. There is a lot more that the install script does than just extracting the latest tarball in a directory.

That will break the usecase for which homebrew on Linux was created so that's unlikely to happen.

See above. Use case is already broken when sudo is found.

[SMillerDev]

Standards by the platform or standards set by homebrew developers?

Standard homebrew prefixes.

To be honest I would be happy with an override to just install in my local home directory. But /home/linuxbrew doesn't fit either.

So just fork the install script, edit it and see what breaks.

It's allowed but intentionally made difficult. There is a lot more that the install script does than just extracting the latest tarball in a directory.

Because the default locations are the only locations that are tested.

[danielnachun]

The install script checks to see if sudo is available for the current user and then uses /home/linuxbrew/.linuxbrew and not $HOME/.linuxbrew. If sudo isn't available then it defaults back to the users home directory. To be honest I would be happy with an override to just install in my local home directory. But /home/linuxbrew doesn't fit either.

I sometimes need to set up an alternate prefix in CI environments with sudo access and it turns out you can just move the whole Homebrew directory after installing it to whatever prefix you want. You have to make sure no formulae are installed when you do this, but Homebrew itself does not, to my knowledge, hardcode the prefix in any of its own code. It just derives it from the current location of brew. This is still not an officially supported thing to do, but it is something I think can be automated. I am not opposed to the idea of providing users with a way to override the default installation path with an environment variable, and this could be a reasonable PR to submit to https://github.com/Homebrew/install.

[nreith]

I have read in some places that it seems like installing the standard way with sudo into /home/linuxbrew allows you after to possibly move that folder anywhere you like after the fact and brew still works with precompiled binaries as long as you set the prefix variable correctly.

This link made me realize that you could simulate this with unshare linux cli utility to basically lie and tell brew up is down. https://unix.stackexchange.com/questions/237636/is-it-possible-to-fake-a-specific-path-for-a-process

But why is this necessary? Docs go to great pains to point out how secure brew is and that it doesn’t use sudo except for creating this super special folder. They won’t even let you run the script as sudo or root, but only prompt you for the password for that one command.

So let me just humbly say, this is really stupid. It removes one of the most valuable use cases for brew, the common situation where you are doing dev or debugging in a corporate environment that does not allow sudo. There should be interest in a non sudo install in user land.

[SMillerDev]

This is necessary because the vast majority of all software hardcodes the path. You can move brew, but if, for example, GCC expects everything to be in the old place it will simply break.

The reason brew is so strict about the paths isn't because it really thinks they are better, it's because CI builds binaries with those paths baked in, so the experience is just significantly better.

[Bo98]

It's not an easy problem to solve.

The problem is simply this: some software bake in install paths at build-time and thus many pre-built bottles won't work and you will have to install things from source. It's for this reason that we warn. Homebrew itself does support non-default prefixes and likely always will but we warn you it's not a good idea because installing packages by building from source takes significantly longer (i.e. potentially hours rather than seconds) and has a substantially increased error rate. The warnings are there to make sure you are aware that the user experience isn't as good and may be more likely to break rather than innocently picking an option without knowing. We've tried softer warnings in the past but there was a frequent bug report volume from people ignoring the warnings and complaining about the build-from-source experience.

The automated installer is the only part that errors out. When installed, Homebrew itself will never refuse to work on a non-default prefix (but may warn). For those who are ok with the pitfalls of non-default prefixes, we offer an alternative install: https://docs.brew.sh/Installation#untar-anywhere-unsupported

In terms of how could this be improved in the future: ideally we'd have some way to binary patch things to allow more packages to be portable/relocatable. We tried approaching this problem before but didn't find a solution at the time.