5 ms·

Always good news to see progress in Brewland. I personally do not like having it installed in /usr/local and have ensured it never is on my installation, but I'

by vr46 10y ago

Always good news to see progress in Brewland. I personally do not like having it installed in /usr/local and have ensured it never is on my installation, but I've not had the chance to ever discuss with one of their team why they do it and what things may possibly explode by not having Brew installed to /usr/local

dancek 10y ago
At least you're missing out on bottles (pre-built formulae) when your prefix is not /usr/local. EDIT: The rationale for using /usr/local has been explained in the FAQ: https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why-does-homebrew-prefer-i-install-to-usrlocal https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why...
- lloeki 10y ago
  The points are opinionated (which is nice!) but a tad obsolete these days. 1. /usr/local/bin is already in your PATH But not /usr/local/sbin, which I had to add anyway. 2. Tons of build scripts break Not that much anymore, and gems can now be configured much more easily thanks to bundler. It's indeed a chore to tell configure to link against this or that, but most of the time you just build a package anyway (trivial with pacman/abs) for things to be managed. 3. no need to worry about messing up existing tools. But many third party tools install stuff in /usr/local. Also, SIP prevents any mess from happening to system stuff. Also, regarding sudo: But do you trust the multi-megabyte Makefile that Homebrew runs? No I don't, that's why make/make install gets run as a regular user but under fakeroot when packaging with, say, pacman/abs. Running the install phase as root allows the package manager to make things just work, such as installing OpenVPN (which depends on tuntaposx kexts), or install daemons under their own user and have them launched on system boot (not user login) by /Library/LaunchDaemons, or install Python under /Library/Frameworks (which ironically, brew builds as a framework but stores somewhere else). Again, those are tradeoffs and it's good that a stance is taken either way. Disclaimer: long-time tentative maintainer of Arch OS X
keithly 10y ago
Where do you have it installed instead?
- jfb 10y ago
  $HOME/.homebrew
mikemcquaid 10y ago
We put as much stuff as possible in `/usr/local/Homebrew` and `/usr/local/Cellar` now so hopefully that helps a bit. `/usr/local/bin` and friends are now mostly just symlinks. As mentioned in another comment, we've got some historical and current reasons for this location and build our binary packages (bottles) for there but you can install Homebrew in any location you want: https://github.com/Homebrew/brew/blob/master/docs/Installation.md#alternative-installs https://github.com/Homebrew/brew/blob/master/docs/Installati...
- vr46 10y ago
  Bottles are good. But I've never hit those other problems, while I have hit issues through using /usr/local. Perhaps your release of Homebrew is better and safer than you expected? :D
- deleted 10y ago
  [deleted]
bluejekyll 10y ago
For C libraries, having it in /usr/local is a benefit, since many already default to looking there, like cmake and autoconf scripts. Otherwise you have to fix that for many build scripts. While I share your misgivings about sticking stuff like this at the "system" level, I think they are right to do so in this case, for simplicities sake.
- snuxoll 10y ago
  /usr/local is explicitly for user/administrator managed software versus /usr being for system managed stuff, it's the correct location for this on any UNIX/POSIX-like system.
  - bluejekyll 10y ago
    Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts. For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.
    - vr46 10y ago
      Having brew install to ~user would be grand, not just for portability, but also to isolate it across users.
      - jfb 10y ago
        I do this. It's simple enough to install homebrew, to, say, $HOME/.homebrew. I haven't had any problems with this approach, but then, I don't use Ruby, and if I did I wouldn't use homebrew to manage it.
        samatman 10y ago
        Except when you run Homebrew? I mean, I understood you, I'm fairly sure brew is the only Ruby command I run on a regular basis...

by vr46 10y ago

dancek 10y ago

At least you're missing out on bottles (pre-built formulae) when your prefix is not /usr/local. EDIT: The rationale for using /usr/local has been explained in the FAQ: https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why-does-homebrew-prefer-i-install-to-usrlocal https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why...

lloeki 10y ago
The points are opinionated (which is nice!) but a tad obsolete these days. 1. /usr/local/bin is already in your PATH But not /usr/local/sbin, which I had to add anyway. 2. Tons of build scripts break Not that much anymore, and gems can now be configured much more easily thanks to bundler. It's indeed a chore to tell configure to link against this or that, but most of the time you just build a package anyway (trivial with pacman/abs) for things to be managed. 3. no need to worry about messing up existing tools. But many third party tools install stuff in /usr/local. Also, SIP prevents any mess from happening to system stuff. Also, regarding sudo: But do you trust the multi-megabyte Makefile that Homebrew runs? No I don't, that's why make/make install gets run as a regular user but under fakeroot when packaging with, say, pacman/abs. Running the install phase as root allows the package manager to make things just work, such as installing OpenVPN (which depends on tuntaposx kexts), or install daemons under their own user and have them launched on system boot (not user login) by /Library/LaunchDaemons, or install Python under /Library/Frameworks (which ironically, brew builds as a framework but stores somewhere else). Again, those are tradeoffs and it's good that a stance is taken either way. Disclaimer: long-time tentative maintainer of Arch OS X

keithly 10y ago

Where do you have it installed instead?

jfb 10y ago
$HOME/.homebrew

mikemcquaid 10y ago

We put as much stuff as possible in `/usr/local/Homebrew` and `/usr/local/Cellar` now so hopefully that helps a bit. `/usr/local/bin` and friends are now mostly just symlinks. As mentioned in another comment, we've got some historical and current reasons for this location and build our binary packages (bottles) for there but you can install Homebrew in any location you want: https://github.com/Homebrew/brew/blob/master/docs/Installation.md#alternative-installs https://github.com/Homebrew/brew/blob/master/docs/Installati...

vr46 10y ago
Bottles are good. But I've never hit those other problems, while I have hit issues through using /usr/local. Perhaps your release of Homebrew is better and safer than you expected? :D
deleted 10y ago
[deleted]

bluejekyll 10y ago

For C libraries, having it in /usr/local is a benefit, since many already default to looking there, like cmake and autoconf scripts. Otherwise you have to fix that for many build scripts. While I share your misgivings about sticking stuff like this at the "system" level, I think they are right to do so in this case, for simplicities sake.

snuxoll 10y ago
/usr/local is explicitly for user/administrator managed software versus /usr being for system managed stuff, it's the correct location for this on any UNIX/POSIX-like system.
- bluejekyll 10y ago
  Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts. For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.
  - vr46 10y ago
    Having brew install to ~user would be grand, not just for portability, but also to isolate it across users.
    - jfb 10y ago
      I do this. It's simple enough to install homebrew, to, say, $HOME/.homebrew. I haven't had any problems with this approach, but then, I don't use Ruby, and if I did I wouldn't use homebrew to manage it.
      - samatman 10y ago
        Except when you run Homebrew? I mean, I understood you, I'm fairly sure brew is the only Ruby command I run on a regular basis...