I like this change. Can we think of any circumstances where someone is using $(brew --prefix) where it turns out they meant $(brew --repository) and this could cause trouble? git commands should fail benignly, which seems okay.

Seems like a good idea, especially with Apple moving to lock down /usr/local more. Keeps things cleaner. Will need a bit of time to think if there are repercussions to this, but don't see any off the bat.

👍 on the idea. Owning less of /usr/local is definitely a good step. Haven't tested the implementation yet, but the idea is a reasonable one.

ohai "This script will install:"
puts "#{HOMEBREW_PREFIX}/bin/brew"
puts "#{HOMEBREW_PREFIX}/share/doc/homebrew"
puts "#{HOMEBREW_PREFIX}/share/man/man1/brew.1"
puts "#{HOMEBREW_PREFIX}/share/zsh/site-functions/_brew"
puts "#{HOMEBREW_PREFIX}/etc/bash_completion.d/brew"
puts "#{HOMEBREW_REPOSITORY}/Library/..."

We should be installing all these (except the last, which should probably be replaced with HOMEBREW_REPOSITORY alone), but I'm only seeing a ln -sf for bin/brew.

Also, after this change we're going to see weird paths like /usr/local/Homebrew/Library/Homebrew, right? Do we still need the Homebrew subdirectory in Library after this change? Of course migration might be an issue, but otherwise the subdirectory seems useless.

Can we think of any circumstances where someone is using $(brew --prefix) where it turns out they meant $(brew --repository) and this could cause trouble? git commands should fail benignly, which seems okay.

Yeh, this is somewhat possible but unavoidable. Thankfully the case where they use $(brew --prefix) but meant $(brew --repo) means they'll be e.g. looking for core Homebrew files rather than e.g. the Cellar or installed files so it's a lot more "implementation-detaily" (even if those have been documented correctly for a long time).

Oh, also: well done @chdiza, you changed the Homebrew default 😀

We should be installing all these (except the last, which should probably be replaced with HOMEBREW_REPOSITORY alone), but I'm only seeing a ln -sf for bin/brew.

They are all installed by the later brew update. We could do that manually but I'm kinda meh on the code duplication and tying more installer code to locations in Homebrew's repository. Agreed about changing the last, will do that.

Also, after this change we're going to see weird paths like /usr/local/Homebrew/Library/Homebrew, right? Do we still need the Homebrew subdirectory in Library after this change? Of course migration might be an issue, but otherwise the subdirectory seems useless.

Yep. A bit part of the motivation for this change is being able to move around the contents of our repository without dumping crap in /usr/local's root any more. We may well be able to move all that stuff to lib or src or similar.

They are all installed by the later brew update.

Oh, good to know, that's good enough.

@zmwangx Improved messaging in 2182f13

especially with Apple moving to lock down /usr/local more.

@apjanke what are you referring to here?

@ilovezfs If nothing else: they reset permissions on every major OS upgrade which is a) annoying b) a bit of a sign that they don't consider our permission changes there to be desirable.

Pretty sure that's basically unintentional since /usr/local doesn't even exist in the default installation.

In any case, I'm not sure what's been achieved with respect to /usr/local unless the actual default non-relocatable bottle installation path changes. But increasing encapsulation of the brew repo is a sufficient reason even if I see nothing else being achieved.

In any case, I'm not sure what's been achieved with respect to /usr/local unless the actual default non-relocatable bottle installation path changes.

Yep, we're not changing the default there so there will still be /usr/local/Cellar and respective symlinks in /usr/local/bin but we just punt the repo elsewhere.

they don't consider our permission changes there to be desirable.

Well of course, and I believe that's for good reasons. /usr/local/bin is in /etc/paths right before /usr/bin and /bin, so if /usr/local/bin is owned by johnappleseed, any program running as johnappleseed can write to /usr/local/bin and mask basic utilities in /usr/bin and /bin, which is a security threat. If I see a system with /usr/local owned by johnappleseed and I don't know John installed Homebrew, I would presume it's done by an attacker.

I might be wrong but I think even repairing disk permissions will restore ownership of /usr/local.

any program running as johnappleseed can write to /usr/local/bin

This will remain.

This will remain.

I'm not talking about changing Homebrew's default. Just saying from Apple's point of view it's certainly not desirable.

Yep, we're not changing the default there so there will still be /usr/local/Cellar and respective symlinks in /usr/local/bin but we just punt the repo elsewhere.

FWIW, I think it would be good to start making a list somewhere of potential new locations so people can start cogitating on what actually is going to work best.

FWIW, I think it would be good to start making a list somewhere of potential new locations so people can start cogitating on what actually is going to work best.

I don't think that's going to change any time soon (perhaps ever) because it'd require rebuilding all our bottles and then remove us from the default search path from many other tools.

I don't think that's going to change any time soon (perhaps ever)

I bet this "suddenly" becomes a priority for some unexpected reason. 🔮

Sweet!

I guess I would like it to be /usr/local/homebrew and not with a capital "H". Seeing things starting with capitals in /usr/local is really weird-looking. E.g., the capital "L" in /usr/local/Library has always bugged me. Other software stays lowercase when they dive into /usr/local, e.g., /usr/local/ssl.

because it'd require rebuilding all our bottles

If we had the resources I'd like to bottle/test two default prefixes where the bottle wasn't cellar :any but realistically implementing that with the current CI is just a path to pain.

E.g., the capital "L" in /usr/local/Library has always bugged me.

/usr/local/Frameworks goes in with a capital as well. There's also /usr/local/Caskroom if your Homebrew repo == Homebrew prefix.

Homebrew is less likely to clash with existing locations, in my experience. Regardless: it's done now 😀

the capital "L" in /usr/local/Library has always bugged me

It'll likely change in future but the previous reasoning was because you have ~/Library

/usr/local/Frameworks goes in with a capital as well. There's also /usr/local/Caskroom if your Homebrew repo == Homebrew prefix.

Frameworks at least has an excuse for the capitalization (to be consistent with /Library/Frameworks and /System/Library/Frameworks, and probably some software is expecting a capital). But Homebrew, Library, Caskroom, Cellar have no such excuse. (Library should never have been used in the first place, upper or lowercase, since it's HB-specific and not some general dumping ground for pieces of many programs. I think HB invented that location.)

Homebrew is less likely to clash with existing locations, in my experience

What would already exist in /usr/local/homebrew, that /usr/local/Homebrew would avoid clashing with?

In any case (heh heh), this is a nice change! 😄

especially with Apple moving to lock down /usr/local more.

@apjanke what are you referring to here?

I just meant the SIP introduced with El Capitan. Nothing new in Sierra AFAIK.

@MikeMcQuaid does this PR have any consequences for what should/shouldn't be in https://github.com/Homebrew/brew/blob/master/.gitignore ?

@ilovezfs Unfortunately not until at least after we do the migration and possibly never if we allow people to also keep HOMEBREW_PREFIX and HOMEBREW_REPOSITORY the same. I hate that .gitignore with the 🔥 of a thousand ☀️.

Yeah that .gitignore freaks me out every time I look at it.

@ilovezfs The best/worst thing is that libgit2 doesn't consistently support it meaning many other Git utilities don't support it.

Oh that's just stellar.

Unfortunately not until at least after we do the migration and possibly never if we allow people to also keep HOMEBREW_PREFIX and HOMEBREW_REPOSITORY the same.

Personal temptation is for us to do a hard migration without an opt-out.

@DomT4 Sorry, I mean for people installed in non-/usr/local locations unless we want to start having "HOMEBREW_REPOSITORY is always in a HOMEBREW_PREFIX subdirectory"?

This is great but why not use /usr/local/homebrew? (lowercase)

@sandstrom Personal preference and to match Cellar (which we can't change).

Also, look at the name of the organization ;)

Homebrew is awesome so I won't argue (even though I disagree 😃 ).

Is it configurable?

I'm also in favour of a small letter 'homebrew', in fact I use it like that since the very beginning:

$ brew config
HOMEBREW_VERSION: 0.9.9
ORIGIN: https://github.com/Homebrew/brew.git
...
HOMEBREW_PREFIX: /usr/local
HOMEBREW_REPOSITORY: /usr/local/homebrew
HOMEBREW_CELLAR: /usr/local/homebrew/Cellar
HOMEBREW_BOTTLE_DOMAIN: https://homebrew.bintray.com
...

$ cd /usr/local/
/usr/local $ ls -la
total 8
drwxr-xr-x   16 root  wheel    544 Apr 24 19:00 .
drwxr-xr-x@  11 root  wheel    374 Dec 16  2015 ..
drwxr-xr-x  769 root  wheel  26146 Aug 31 21:11 bin
drwxr-xr-x   23 root  wheel    782 Aug 20 18:59 etc
drwxrwxr-x   15 root  wheel    510 Sep 10 16:29 homebrew
...

/usr/local $ ls -la
total 56
drwxrwxr-x   15 root  wheel   510 Sep 10 16:29 .
drwxr-xr-x   16 root  wheel   544 Apr 24 19:00 ..
drwxr-xr-x   16 root  wheel   544 Sep 10 16:29 .git
drwxr-xr-x    5 root  wheel   170 Sep 10 16:29 .github
-rw-r--r--    1 root  wheel  1141 Aug 20 18:15 .gitignore
-rw-r--r--    1 root  wheel   253 Jul 31 02:34 .travis.yml
-rw-r--r--    1 root  wheel   291 Aug 29  2015 .yardopts
-rw-r--r--    1 root  wheel  3161 Apr  9 18:20 CODEOFCONDUCT.md
drwsr-sr-x  133 root  wheel  4522 Aug 31 21:11 Cellar
-rw-r--r--    1 root  wheel  1241 Dec 31  2015 LICENSE.txt
drwxr-xr-x    8 root  wheel   272 Aug 26 09:32 Library
-rw-r--r--    1 root  wheel  5673 Sep 10 16:29 README.md
drwxr-xr-x    3 root  wheel   102 Aug 26 09:32 bin
drwxr-xr-x    3 root  wheel   102 Apr  9 18:20 etc
drwxr-xr-x    5 root  wheel   170 Apr  9 18:20 share

I'm very happy with that setup (keeps things nice and clean and clearly separated), so I'm rather afraid to brew update...

Will it break/ mess up things? The to-be-killed root "support" is dangling like a Damocles sword too (but no way in hell I'll ever have any user owned files in /usr/local/ on a machine that is shared by multiple accounts) 😱

@sandstrom

Is it configurable?

On a case-sensitive filesystem:

> sudo mv /usr/local/Homebrew /usr/local/homebrew
> ln -sf /usr/local/Homebrew/bin/brew /usr/local/bin/brew
> brew update --force

On a case-insensitive but case-preserving filesystem:

> sudo mv /usr/local/Homebrew /usr/local/Homebrew.bak
> sudo mv /usr/local/Homebrew.bak /usr/local/homebrew

On a case-insensitive and case non-preserving filesystem:

Excuse me?

@zmwangx thanks! I was thinking more of an install flag/option, a prompt when installing or a cli message upon install pointing to docs/info on how to modify.

@sandstrom We surely won't recommend that so putting it in the install script is out of question. We do link to https://github.com/Homebrew/brew/blob/master/docs/Installation.md#installation from http://brew.sh which gives alternative installation instructions, including installing to custom locations. Now /usr/local/homebrew isn't really a custom location (it could be when APFS ships, we don't know if it will be case-insensitive by default just yet), but still, cloning the git repo will always work.

You can install Homebrew wherever you like but the defaults will stay as-is, thanks!