Homebrew 1.1.0(brew.sh)
brew.sh
Homebrew 1.1.0
http://brew.sh/2016/11/07/homebrew-1.1.0/
215 comments
To echo everyone else: Apple should be paying you folks a boat load of money. If homebrew didn't exist, I don't think we'd bother with macOS as a developer environment.
I have mixed feelings about Homebrew. Don't get me wrong, it's great, good job everyone involved. It makes my OSX laptop a viable development option for me. Without Homewbrew I wouldn't use it.
Alas that's also the problem. It makes OSX so familiar that this one OSX machine has now crept into my collection of Linux boxes and won't leave (thank you iOS development). I guess if your only complaint is that the software is too good...that's a pretty great thing :)
Sometimes I wonder how valuable Apple thinks Homebrew is for them. Any info on how much they contribute to the project?
Alas that's also the problem. It makes OSX so familiar that this one OSX machine has now crept into my collection of Linux boxes and won't leave (thank you iOS development). I guess if your only complaint is that the software is too good...that's a pretty great thing :)
Sometimes I wonder how valuable Apple thinks Homebrew is for them. Any info on how much they contribute to the project?
Recently had to reinstall my mac from scratch. I was able to install 95% of my daily software through brew, by far a new record. Big thanks to the developers / maintainers of this project.
As a developer, if it weren't for Homebrew, I'd ditch OS X.
I love homebrew! I have it all on of my macOS machines. Best, easiest way to install common software I use between computers (Where supported, anyway) and developer packages. Now if we could just get http://linuxbrew.sh/ up to the same caliber....:)
It is so much easy to make your code public for everyone to use on Homebrew. Great job maintainers!
Homebrew is one of the great things I love about doing dev on a Mac. /micdrop
It's funny how every hipster dev uses a MacBook for development, yet you have to resort to this kind of hacks from day one if you want to be productive. Anyway.
First order of Action when setting up new Mac install chrome and homebrew :), Fantastic tool keep up the great work.
Anyone here used port? What made you choose brew over port? I'm on the fence here.
The most fitting name for a software I've ever seen!
Docker for mac has replaced homebrew for me. Run anything under the sun in a temporary container and mount the current directory. Works great and is very nice isolating everything
Homebrew is awesome. Comes close to apt.
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
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/Installati...
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
Perhaps your release of Homebrew is better and safer than you expected? :D
[deleted]
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.
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.
/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.
> POSIX
Annoyingly, the FHS isn't POSIX (nor SUS) and thus not Unix. There's thus no real standardisation on what the filesystem should look like and thus even Guix or Gobolinux can be POSIX candidates.
Even macOS takes advantage of this nonstandardisation by putting stuff in /Applications, /Library and /Users.
The debate about what belongs in /usr, /usr/local, /opt (and hahaha, /opt/local) is mostly subjective opinions about just how local these local things are.
Annoyingly, the FHS isn't POSIX (nor SUS) and thus not Unix. There's thus no real standardisation on what the filesystem should look like and thus even Guix or Gobolinux can be POSIX candidates.
Even macOS takes advantage of this nonstandardisation by putting stuff in /Applications, /Library and /Users.
The debate about what belongs in /usr, /usr/local, /opt (and hahaha, /opt/local) is mostly subjective opinions about just how local these local things are.
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.
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.
Having brew install to ~user would be grand, not just for portability, but also to isolate it across users.
We can't relocate many binary packages (bottles) with dynamic paths like that, unfortunately, or we'd do that.
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.
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.
The multiuser features are used to provide defense in depth, especially for developer machines.
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.
Apple's migration tool and cloning have always worked for me.
The multiuser features are used to provide defense in depth, especially for developer machines.
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.
Apple's migration tool and cloning have always worked for me.
One of the issues I recall comes from not using Homebrew exclusively. For example, installing GPG from package puts files in the same location, and I've had conflicts in the past. It's not always possible to use Homebrew exclusively, so I move it elsewhere to mitigate this possible problem.
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...
EDIT: The rationale for using /usr/local has been explained in the FAQ: https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why...
The points are opinionated (which is nice!) but a tad obsolete these days.
Also, regarding sudo:
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
1. /usr/local/bin is already in your PATH
2. Tons of build scripts break
3. no need to worry about messing up existing tools.
Also, regarding sudo:
But do you trust the multi-megabyte Makefile that Homebrew runs?
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
[deleted]
There are lots of minor changes, but nothing major IMHO. The reason for bumping the minor version are a couple of breaking changes:
- Disable SHA-1 checksum support in formulae
- Disable running Homebrew as the root user (e.g. sudo brew)
- Bottles with _or_later tags no longer use _or_later in their filenames so the existing bottle can be reusedSide-topic: Shouldn't the breaking changes be enough reason to bump the version to 2.0?
Unfortunately most people now consider major versions to indicate major feature additions rather than breaking changes.
Yes, it should. But that scares people.
Not really. Signatures should be SHA256 already, you shouldn't be running as root (which as always been frowned upon).
> which as always been frowned upon
Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".
Only in the Homebrew backwards-day world is having globally installed software not owned by root "frowned upon".
Hmmm. The UNIX education that's been hammered into me since childhood has said "If you can do it as not-root, don't do it as root".
relevant discussion here https://github.com/Homebrew/homebrew-core/issues/6677
Of specific interest: "This deprecation was announced and these methods removed/undocumented before 1.0.0 was tagged so arguably it was not part of the public API when 1.0.0 shipped."
I'm ambivalent. If I rev 1.0 - 1.1, then I'm going to assume the API won't change, even if I'm using undocumented and warning-spitting methods.
But I shouldn't be doing that, I shouldn't roll in a minor update without at least reading the change log, it's a FOSS project run by a volunteer staff, and brew never swore an oath to follow the laws of versioning as set by semver.org.
If the brew documentation said, "We use semantic versioning," then I'd say the complainants were correct. Otherwise, versions are just versions, and all you can count on is (Major Changes).(Medium Changes).(Minor Changes).(Tiny Changes).(etc.)
edit: Thoughts:
Years and years ago, I spent a lot of time and energy ranting about the fact that Google called GMail "beta software" when it was clearly not feature complete, and beta has a meaning, and we are just destroying a useful system of names for the software testing and release cycle, and…
But in the end, version numbers and development stages are language, and you cannot force your language on others, irregardless of whether or not you'd like to.
I'm ambivalent. If I rev 1.0 - 1.1, then I'm going to assume the API won't change, even if I'm using undocumented and warning-spitting methods.
But I shouldn't be doing that, I shouldn't roll in a minor update without at least reading the change log, it's a FOSS project run by a volunteer staff, and brew never swore an oath to follow the laws of versioning as set by semver.org.
If the brew documentation said, "We use semantic versioning," then I'd say the complainants were correct. Otherwise, versions are just versions, and all you can count on is (Major Changes).(Medium Changes).(Minor Changes).(Tiny Changes).(etc.)
edit: Thoughts:
Years and years ago, I spent a lot of time and energy ranting about the fact that Google called GMail "beta software" when it was clearly not feature complete, and beta has a meaning, and we are just destroying a useful system of names for the software testing and release cycle, and…
But in the end, version numbers and development stages are language, and you cannot force your language on others, irregardless of whether or not you'd like to.
> I'm going to assume the API won't change, even if
> I'm using undocumented and warning-spitting methods.
And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.
And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.
>And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.
We're in complete agreement, actually. I'm just saying that I generally don't expect things like that to change on a point release, not that it can't, won't, or shouldn't. You're definitely juggling chainsaws if you're in a situation like that.
We're in complete agreement, actually. I'm just saying that I generally don't expect things like that to change on a point release, not that it can't, won't, or shouldn't. You're definitely juggling chainsaws if you're in a situation like that.
In this case it was documented.
> Disable running Homebrew as the root user (e.g. sudo brew)
why? Just curious, because I always use macports with sudo.
why? Just curious, because I always use macports with sudo.
We don't drop privileges when building (as we're not designed to run as root) and the macOS sandbox has issues with the root user so unfortunately you're giving every package you install root access to write to (almost) anywhere on your system. This is bad so we've stopped it.
> We don't drop privileges when building
So why did you choose to disable running as root altogether rather than dropping privileges when building?
So why did you choose to disable running as root altogether rather than dropping privileges when building?
Using the root user like this is used by a tiny minority of our users. The deprecation notice noted we'd happily accept a PR that implemented the privilege dropping but one never came. In a world where Homebrew is run by a full-time, paid staff we'd likely have implemented it but there's too much other, more important stuff that needs done by our understaffed team.
I assume it's because 1) it's not really needed, and 2) it prevents shady packages from executing scripts as root.
IIRC because it could cause problems with overwriting system libraries in earlier versions, so it has long been deprecated.
Homebrew maintainers are doing a fantastic job, made my life as a developer so much easier! I wanna use this opportunity to "publicly" thank them!
Agreed. Homebrew has saved countless hours for developers, I can't believe how many hours I used to spend installing/updating different versions for testing. Now we just run (>brew switch package version) done.
Whoaaa didn't know that command. This could replace something like say nvm?
It maybe could be hacked into replacing it but I'd not recommend it. Better to use a dedicated tool that handles this stuff more cleanly e.g. nvm.
I don't think so. In my experience brew only has a very limited selection of versions of packages, which is understandable.
It probably could.
But I'm not sure if brew has everything or is updated faster than nvm.
But I'm not sure if brew has everything or is updated faster than nvm.
I don't like 'me too's, but Homebrew has been absolutely invaluable to me. The icing on the cake is that I can just install my own software in /usr/local/Cellar/<name>/<version> or make my own tap and enjoy many of the benefits of Homebrew.
Thanks Homebrew maintainers, you make macOS rock even more!
Thanks Homebrew maintainers, you make macOS rock even more!
Ditto. I install almost everything via brew and brew cask, and store the list of packages in git. It makes setting up a new machine a breeze. Thanks for all your hard work!
This is a cool idea! How does one go about doing this though? Is there a flag to output a text file with the names of installed versioned packages?
The officially supported thing is:
https://github.com/Homebrew/homebrew-bundle
See my Brewfile in my dotfiles for how I use it to install my stuff: https://github.com/MikeMcQuaid/dotfiles/blob/master/Brewfile
If you want to go a step further there's also Strap which will bootstrap your macOS system with some sensible defaults and install Homebrew, your dotfiles and your Brewfile: https://github.com/mikemcquaid/strap
Finally, if you're interested how I combined these to replace Boxen at GitHub (our macOS system/project bootstrap tool using Puppet) read this: http://mikemcquaid.com/2016/06/15/replacing-boxen/
See my Brewfile in my dotfiles for how I use it to install my stuff: https://github.com/MikeMcQuaid/dotfiles/blob/master/Brewfile
If you want to go a step further there's also Strap which will bootstrap your macOS system with some sensible defaults and install Homebrew, your dotfiles and your Brewfile: https://github.com/mikemcquaid/strap
Finally, if you're interested how I combined these to replace Boxen at GitHub (our macOS system/project bootstrap tool using Puppet) read this: http://mikemcquaid.com/2016/06/15/replacing-boxen/
This is utterly brilliant! Thank you.
I've been looking like this for quite a while. I'm still looking through it all, but I don't suppose you have a solution for setting System Preferences, particularly Trackpad settings and remapping the Caps Lock key to Ctrl?
I've been looking like this for quite a while. I'm still looking through it all, but I don't suppose you have a solution for setting System Preferences, particularly Trackpad settings and remapping the Caps Lock key to Ctrl?
I don't use it but https://github.com/benbalter/plister should do that. There's an open issue to integrate it with Strap, too: https://github.com/benbalter/plister/issues/2
Here's one example: https://github.com/geerlingguy/mac-dev-playbook
Makes it a lot simpler to do a clean OS install every upgrade, and to make sure all three of my Macs are perfectly in sync!
Makes it a lot simpler to do a clean OS install every upgrade, and to make sure all three of my Macs are perfectly in sync!
Using brew bundle, run `brew bundle --help` for info. I then store the Brewfile along with my other dotfiles
Here's another example of a simple shell script I use to do this: https://github.com/spinningarrow/up/blob/master/up
I use `brew bundle` for this.
__pid_t(2)
Probably stupid question but: how do you update your version?
Try:
$ brew update # get latest version of Homebrew
$ brew cleanup # Homebrew housekeeping
$ brew cask cleanup # Cask housekeeping
$ brew --version
#Expected output: Homebrew 1.1.0brew update
I just tried `brew upgrade` but that is upgrading not itself, but every package installed with it instead. >:-&
`brew update` i imagine
Pretty sure just brew update.
That's what I thought, but after running that it doesn't log any sort of version update.
brew update: updates formulae and Homebrew itself.
brew upgrade: updates everything.
brew upgrade: updates everything.
I'm going to ditto the positive comments. Kudos to the maintainers - not just for the package itself but for growing it. They successfully went from a hacky page with some scripts, to a big giant repository, to multiple repos, to a fully fledged mature best-practices package manager for macOS with all the bells and whistles.
The sign of a great project isn't just that it does one thing well, but that it grows with the needs of the users and engages with them to constantly make something better without falling prey to bloat. And by that measure, Homebrew gets a gold star.
The sign of a great project isn't just that it does one thing well, but that it grows with the needs of the users and engages with them to constantly make something better without falling prey to bloat. And by that measure, Homebrew gets a gold star.
Thanks for the kind words. You'd be surprised how motivating they are. <3
I started writing a package manager example app, and I quickly learned how much work goes into creating a good one. Ever since I have been grateful for any work others put into working on package management!
stephenr(1)
Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?
Macports. It works and does what I need it to do. I switched to Mac from Linux, and with that background it was unnerving to see a system deliberately written to install non-root-owned files in /usr, so I ruled Homebrew out. I've always found it puzzling that people ask whether anyone "still" uses Macports, as though it is some decrepit thing. Homebrew is the one that seems strange to me.
My thoughts exactly.
I'm a daily linux user, but occasionally some job requires me to use a Mac. Every time I see some OSX tool that starts with the premise of "just go ahead and `sudo chown` a system location and then curl this script into a `sudo bash` pipe" I just think to myself, if they care so little about security to not get the easy stuff right, can I really expect them to nail the hard stuff?
Usually not. I'll have to give Macports a try. As I understand it, it's an implementation/port of the BSD ports system, so I'd expect it to have a more solid foundation.
I'm a daily linux user, but occasionally some job requires me to use a Mac. Every time I see some OSX tool that starts with the premise of "just go ahead and `sudo chown` a system location and then curl this script into a `sudo bash` pipe" I just think to myself, if they care so little about security to not get the easy stuff right, can I really expect them to nail the hard stuff?
Usually not. I'll have to give Macports a try. As I understand it, it's an implementation/port of the BSD ports system, so I'd expect it to have a more solid foundation.
I switched to MacPorts from Fink (RIP). It feels about the same as using pkg on a modern FreeBSD box. Pros compared to Homebrew: doesn't litter symlinks everywhere, behaves the way you expect a package manager to. Cons: Not as cool™, tends to have less frequently updated packages.
I still use macports! As for why, there are a couple of reasons.
First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new version of Openssh will break any core Mac OS components.
First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new version of Openssh will break any core Mac OS components.
Macports doesn't really rely on anything OS-X specific except for Xcode
And that's a big problem right there, I don't use xcode and its also a 15GB install!, so a waste to my small 128GB ssd.
Not to mention you will get nagging updates of a huge app you don't use, which takes lots of time to download and install.
Why doesn't macports make their pkg manager work just with the xcode cli tools? and for those pkgs that need xcode, tell the user they need to install xcode first.
And that's a big problem right there, I don't use xcode and its also a 15GB install!, so a waste to my small 128GB ssd.
Not to mention you will get nagging updates of a huge app you don't use, which takes lots of time to download and install.
Why doesn't macports make their pkg manager work just with the xcode cli tools? and for those pkgs that need xcode, tell the user they need to install xcode first.
> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution
This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO) since you face fewer issues with breakage. OS X can update its userland tools and you generally don't care.
This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO) since you face fewer issues with breakage. OS X can update its userland tools and you generally don't care.
This is also exactly why i use MacPorts. It works. It doesn't do silly stuff. It's been consistently solid for years.
Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was to sudo -i to my primary account in a shell.
Don't get me started on "brew install docker" vs "brew cask install docker".
That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was to sudo -i to my primary account in a shell.
Don't get me started on "brew install docker" vs "brew cask install docker".
That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
> That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
You are probably using on old version of OS X that does not yet support TLS 1.2. Therefore system's libcurl cannot talk to https://kernel.org anymore, which got very strict recently. As a workaround, you can download the tarball manually with your browser and place it into /opt/local/var/macports/distfiles/git/.
https://trac.macports.org/ticket/52604
You are probably using on old version of OS X that does not yet support TLS 1.2. Therefore system's libcurl cannot talk to https://kernel.org anymore, which got very strict recently. As a workaround, you can download the tarball manually with your browser and place it into /opt/local/var/macports/distfiles/git/.
https://trac.macports.org/ticket/52604
Homebrew maintainer view: MacPorts is a good package manager built by smart people and we end up sharing e.g. patches sometimes. I used to use it before Homebrew and it was good. Nowadays it's worth using whichever one takes the approach that feels best to you.
I use pkgsrc due to portability and its clean separation between the base system and itself.
https://pkgsrc.joyent.com/install-on-osx/
https://pkgsrc.joyent.com/install-on-osx/
Pkgsrc is fantastic and never gave me the lib conflict headaches I had with Homebrew. It's also really easy to contribute a package or fix. Plus I use pkgsrc in the cloud, so my dev machine works like my production machine.
Can't say enough good things about pkgsrc.
Can't say enough good things about pkgsrc.
MacPorts user here. It keeps ALL of its stuff in a single directory, and you just have to add it to the path. All package managers screw up from time to time, however MacPorts mistakes/inconsistencies are easily fixed, Homebrew has always been a pain in the ass for me. Also, no telemetry.
I do. I don't have anything against brew, I think it is great that it is available, but I've used Macports since before brew existed. Macports' philosophy and where it puts things just seems to jive more with how I think that type of tool should work and behave. There also might be a little bit of unjustifiable anti-ruby bias on my part at work there too. I'm glad both alternatives exist.
I use macports. No particular reason, it just works for me and I don't see any reason to switch. It also feels more BSD-like, which is a plus for me, though I didn't dig deep enough.
Yes. MacPorts. Quality and stability.
$ sudo port install texlive +full
> Error: No available formula with the name "texlive"
> ...
> You can install it with Homebrew-Cask:
> brew cask install mactex
Maybe they updated the error message. Here is what it said that last time I tried Homebrew:
$ brew info texlive
Installing TeX from source is weird and gross, requires a lot of patches,
and only builds 32-bit (and thus can't use Homebrew deps on Snow Leopard.)
We recommend using a MacTeX distribution: https://www.tug.org/mactex/We did update it, yep.
Here is one more reason I use MacPorts, because it never does crap like this:
$ brew search x11
x11vnc
Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Try again in 54 minutes 49 seconds, or create a personal access token:
https://github.com/settings/tokens
and then set it as HOMEBREW_GITHUB_API_TOKEN.This is not a Homebrew issue. This is a Github issue. The instructions regarding the API token solve the problem.
How often are you querying GitHub's API from your local machine?
I can answer that that precisely: 4. I was testing Homebrew in a virtual machine to see how it compared to MacPorts, Nix, and Pkgsrc at the time and can restore the virtual machine with Terminal still open and my complete session viewable.
Sure the "fix" is simple. But when I'm evaluating something I'm possibly going to make part of my life, I have to ask myself: how many more surprises await me?
Based on my evaluation of the available package managers, my ranking (for macOS) is:
1) MacPorts 2) Pkgsrc 3) Homebrew 4) Nix
Sure the "fix" is simple. But when I'm evaluating something I'm possibly going to make part of my life, I have to ask myself: how many more surprises await me?
Based on my evaluation of the available package managers, my ranking (for macOS) is:
1) MacPorts 2) Pkgsrc 3) Homebrew 4) Nix
I've encountered that error too. Sometimes, I am just seeing if stuff I want to play with are out there in brew land.
Nix package manager on my Mac [1]. Deterministic builds, plays well with POSIX/UNIX, though fewer repo's available than Brew and others.
[1]:https://news.ycombinator.com/item?id=11772686
[1]:https://news.ycombinator.com/item?id=11772686
I tried switching to nix, but homebrew's command line argument "design" has spoiled me. With homebrew I'm usually able to guess command arguments, where as with every other package manager I have to google when I want to do something I haven't done before.
For example, I want to search for a package name before installing. I'm guessing it's just "brew search pkg"... yup. Now what do I do with nix? Google says it's "nix -qa pkg", that totally makes sense, and I just love how I have to memorize some arcane letters.
This is true for virtually every linux package manager I've tried (wtf is apt-cache? I can't remember pacman commands after using it for a year). Seriously, typing anything with a minus sign is slower than typing word, so what's even the point? At this point I won't (choose to) use a package manager that doesn't get this right.
For example, I want to search for a package name before installing. I'm guessing it's just "brew search pkg"... yup. Now what do I do with nix? Google says it's "nix -qa pkg", that totally makes sense, and I just love how I have to memorize some arcane letters.
This is true for virtually every linux package manager I've tried (wtf is apt-cache? I can't remember pacman commands after using it for a year). Seriously, typing anything with a minus sign is slower than typing word, so what's even the point? At this point I won't (choose to) use a package manager that doesn't get this right.
Haha, this is true, Nix's commandline is not exactly intuitive. I've been using apt, vim, and other similarly unintuitive stuff for a long time though so I just deal with it or script it, but totally understand anyone who prefers something more semantic.
Basically all of the unixy tools I need host-side (a lot of my work happens in Debian VM's or on remote Debian servers) are available as native Installer Packages (.pkg or .mpkg bundles)
This boils down to: Vagrant, Mercurial, Git, GPG Suite, Autotools, tree and wget.
This boils down to: Vagrant, Mercurial, Git, GPG Suite, Autotools, tree and wget.
I do. Its nice an isolated and just works. I like how the options work.
I have been very happy with Homebrew some far. What are some good windows alternative? Making the move from OSX to Windows in a week.
I switched to Windows last year for work after having worked primarily on Debian and OSX.
Chocolatey is the best that I've found. I have run into issues though, so I can't say it's perfect or even close. It's not bad though.
https://chocolatey.org/
Also depending on the type of development you do, you may be able to use Bash On Windows and use ubuntu's apt for everything.
Chocolatey is the best that I've found. I have run into issues though, so I can't say it's perfect or even close. It's not bad though.
https://chocolatey.org/
Also depending on the type of development you do, you may be able to use Bash On Windows and use ubuntu's apt for everything.
Windows 10 now has support for the Ubuntu subsystem. You have to flip some settings to enable it and install it, but it's very easy to setup and it creates a complete Linux shell within Windows, including full support for apt-get.
I found the default terminal pretty lacking, but you can now use mintty as the terminal: https://github.com/mintty/wsltty
With this, it's possibly a better Unix experience than macOS. I haven't used it enough to confidently make such a big statement, but it's worked very well so far in my trials.
I found the default terminal pretty lacking, but you can now use mintty as the terminal: https://github.com/mintty/wsltty
With this, it's possibly a better Unix experience than macOS. I haven't used it enough to confidently make such a big statement, but it's worked very well so far in my trials.
If you want Unix-like software, look at msys2 (http://msys2.github.io/). Its package manager is Pacman (the same as Arch Linux).
When I have to use a Windows machine I basically do everything in a msys2 terminal.
When I have to use a Windows machine I basically do everything in a msys2 terminal.
I would recommend chocolatey or Npackd, however chocolatey cannot detect what you have already installed on hard disk.
Disabling sha1 does not seem like a good decision. There are still enough upstream software projects that only publish their checksums as sha1 or even only md5. Keeping the original checksum allows quick comparison that a Formula is meant to use the same tarballs that were published by upstream. The problems of algorithms such as sha1 or md5 can be remedied by an additional strong checksum in the Formula. Checksum calculation is so fast that doing it twice will not matter.
Homebrew does, in fact, always use its own strong additional checksum (sha256) in the individual Formulae for all downloaded resources.
There is nothing wrong with calculating your own additional checksum, but as far as I can see, sha256 is now the only supported checksum type in Homebrew at all.
floatrock(1)
I have very mixed feelings about homebrew. When it works, it is awesome, but when it doesn't it can be a serious nightmare. In particular, homebrew refuses to run under sudo. Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). I have mostly stopped using it for this reason.
I understand that running a program that runs third-party scripts under sudo is a security nightmare, but there has to be a better solution than globally chowning /usr/local.
[UPDATE] Apparently, this is no longer the case. Good to know!
[UPDATE2] Alas, the problem seems to not have been fully addressed. You still need to chown /usr/local/bin :-(
I understand that running a program that runs third-party scripts under sudo is a security nightmare, but there has to be a better solution than globally chowning /usr/local.
[UPDATE] Apparently, this is no longer the case. Good to know!
[UPDATE2] Alas, the problem seems to not have been fully addressed. You still need to chown /usr/local/bin :-(
Just install to a different folder. Everything still works.
I wonder how much of this could have been avoided if they defaulted to a different, user created folder.
> recursively chown /usr/local to myself
As of 1.0.0: you don't need to do this any more and we don't ask you to.
As of 1.0.0: you don't need to do this any more and we don't ask you to.
I'm on an older version (0.9.5); how do I fix the ownership of my /usr/local tree?
EDIT: I know how to `chown`, I mean more, what can I give back to root, what needs to remain under homebrew's control? Does the new version ship with a tool/command that does this?
EDIT: I know how to `chown`, I mean more, what can I give back to root, what needs to remain under homebrew's control? Does the new version ship with a tool/command that does this?
`brew update` and check you've not hit the update bug: https://github.com/homebrew/brew#update-bug
We'll tell you what permissions you need to keep/remove. Alternatively, uninstall and reinstall Homebrew and similarly we'll tell you on permissions.
We'll tell you what permissions you need to keep/remove. Alternatively, uninstall and reinstall Homebrew and similarly we'll tell you on permissions.
Ah, that is very good to know! Thank you! I will take a fresh look at homebrew. :-)
To perhaps save you some effort: we still ask you to chown e.g. `/usr/local/bin` which may or may not make it unacceptable to you.
That's not quite as bad as all of /usr/local, but still not great. Why "e.g."? What else is there? And why not just use /usr/local/homebrew or even better, a path determined by an environment variable? I don't mind giving you a user-owned directory to install things in. I mind very much being required to change system default security settings.
You can use a different directory, though some packages may be broken:
https://github.com/Homebrew/brew/blob/master/docs/Installati...
https://github.com/Homebrew/brew/blob/master/docs/Installati...
Yeah, that's kind of the situation I'm in. So for any given package it's a crap shoot whether or not it will work. (And if it doesn't work, uninstalling it can be a real problem!) Hence my continued mixed feelings about homebrew in general.
We don't require you to take ownership of any directories that already exist when macOS is installed (i.e. `/usr/local` subdirectories but not `/usr/local` itself). Regardless of whether we should have picked another path, changing now would require rebuilding all our binary packages and that's a lot of effort with little return and almost certain breakages.
I haven't done a clean install of OS X in a long time, but I'm pretty sure /usr/local/bin exists. But even if it doesn't I don't find this a compelling argument. Having /usr/local/bin owned by root is a universally accepted standard in the unix world, and with very good reason: having /usr/local/bin owned by a user introduces security risks.
`/usr/local` is empty on a new install. I reconfirmed with a clean install VM.
What are those risks?
/usr/local/bin is a global resource. It is generally full of binaries that get run by many different users including root. If a regular user can replace those binaries the result is a privilege escalation.
which programs from /usr/local/bin get run by root under current macOS?
Well, by default /usr/local/bin is empty. But people commonly install things there that eventually get run by root. The most obvious example is various programming languages, different versions of Python, alternate shells, etc.
[deleted]
(Reaching back into foggy memory...) The last time I installed Homebrew, I think I had the problem that `/usr/local/bin` didn't exist, and I didn't have write permissions for `/usr/local/` so I couldn't create it (w/out sudo/chown) etc. This, using Sierra.
Does that seem likely? Usual? What's the ideal solution?
Does that seem likely? Usual? What's the ideal solution?
You need to use `sudo` as a one-off thing when you install Homebrew. Our installer does that for you otherwise we'll prompt you with `brew doctor`.
Why don't you have your binaries installed in a user-owned directory like ~/brew or whatever, and then put that at the front of the path? Asking people to `chown` a system path is plainly a contravention of the principle of least privilege.
`~/brew` varies from username to username and requires us to be able to relocate all binaries so they reference the correct path. We do this for as many as possible but it's not possible for all of them.
Isn't it desirable to run builds as not-root?
If you're concerned about safety, you could maybe "freeze" your homebrew install by chowning /usr/local back to root in between brew invocations.
If you're concerned about safety, you could maybe "freeze" your homebrew install by chowning /usr/local back to root in between brew invocations.
> Isn't it desirable to run builds as not-root?
Absolutely. That's why the canonical gnu installation separates "make" from "make install". But homebrew could do the same thing (and maybe it does now -- I need to go back and revisit this because apparently this issue has been resolved.)
Absolutely. That's why the canonical gnu installation separates "make" from "make install". But homebrew could do the same thing (and maybe it does now -- I need to go back and revisit this because apparently this issue has been resolved.)
Very much the reason why MacPorts requires sudo, so it can drop to a less-privileged "macports" user for builds, without putting your own user account at risk.
Not to rain on anyone's parade, but I find MacPorts to be superior to Homebrew in every way, from writing the ports themselves, to installing them and managing them. I used to use Homebrew some time ago, but when I got my Mac Mini, I decided to forgo it in favor of MacPorts and Pkgsrc (which Joyent also provides binaries of for OSX). Whatever MacPorts doesn't have (a rare occurrence), Pkgsrc tends to have it. If not, writing a MacPort is incredibly easy with their provided DSL.
I was pleasantly surprised that, despite Homebrew taking so much of the OSX package management mind-share these days, MacPorts still has an active and vibrant community going strong. I was also pleasantly surprised by just how well Pkgsrc works on OSX, despite its origins on NetBSD. In fact, Pkgsrc works so well that I've switched to using it on Slackware as my primary package manager for anything not in the base system, preferring it to SlackBuilds.org and sbotools (though I still use sbotools whenever Pkgsrc doesn't have a package I want — which sometimes leads to duplicate dependencies in different paths... still haven't figured out how to avoid that yet...).
I was pleasantly surprised that, despite Homebrew taking so much of the OSX package management mind-share these days, MacPorts still has an active and vibrant community going strong. I was also pleasantly surprised by just how well Pkgsrc works on OSX, despite its origins on NetBSD. In fact, Pkgsrc works so well that I've switched to using it on Slackware as my primary package manager for anything not in the base system, preferring it to SlackBuilds.org and sbotools (though I still use sbotools whenever Pkgsrc doesn't have a package I want — which sometimes leads to duplicate dependencies in different paths... still haven't figured out how to avoid that yet...).
As a side note and in fact late to the party, but MacPorts very recently also migrated to Git and GitHub: https://github.com/macports/
I agree, I prefer MacPorts also. It has a more of a linux/debian package management vibe to it, which I like.
I've tried homebrew also, but it just feels more like a hack put together. Maybe version 1.1.0 is better, but I'm still going to stick with MacPorts.
Each to it's own, but I wish MacPorts would get more coverage in the news and in the OS X development world.
I've tried homebrew also, but it just feels more like a hack put together. Maybe version 1.1.0 is better, but I'm still going to stick with MacPorts.
Each to it's own, but I wish MacPorts would get more coverage in the news and in the OS X development world.
This was a problem for me. I installed Homebrew to my home directory [1] and it works great. I no longer need to chown /usr/local or run any commands under sudo.
[1] https://gist.github.com/jaymcgavren/bb85914950578edabad190c3...
[1] https://gist.github.com/jaymcgavren/bb85914950578edabad190c3...
I do the same (but installed to ~/.homebrew). No issues so far — if anyone knows why this isn't the default, I'd be interested to know.
> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm).
Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed executables in a system-wide path. But the former problem is one you wrestle with anyway if /usr/local is owned by root. And the latter problem... you're going to have some path where you're putting all this stuff, and it's either going to be a personally owned or system owned path. The system-owned choice means giving your package manager sudo and having to run things with sudo (which, without attention, means giving the executables system-wide access). What other problems does a personally owned path create? What's the alternative?
Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed executables in a system-wide path. But the former problem is one you wrestle with anyway if /usr/local is owned by root. And the latter problem... you're going to have some path where you're putting all this stuff, and it's either going to be a personally owned or system owned path. The system-owned choice means giving your package manager sudo and having to run things with sudo (which, without attention, means giving the executables system-wide access). What other problems does a personally owned path create? What's the alternative?
> Why is this a really bad idea for a personal machine?
It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root.
> What's the alternative?
/usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.
It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root.
> What's the alternative?
/usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.
Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.
Also you can actually install it wherever you like, this is just the default/recommended location:
https://github.com/Homebrew/brew/blob/master/docs/Installati...
Also you can actually install it wherever you like, this is just the default/recommended location:
https://github.com/Homebrew/brew/blob/master/docs/Installati...
Other than being in a different directory, what difference is that going to make?
Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.)
You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.
Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise.
Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.
Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.)
You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.
Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise.
Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.
/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
Why would using /opt/homebrew/bin stop these sorts of attacks?
It would prevent privilege escalation attacks on binaries that I have already installed in /usr/local/bin. Yes, packages installed in /opt/homebrew/bin could be attacked separately, but at least the vulnerable binaries are isolated so it's easier to keep an eye on them and make sure none of them are ever run with privileges.
But you're right: to really fix this problem requires that homebrew change its installation process entirely.
But you're right: to really fix this problem requires that homebrew change its installation process entirely.
> What's the alternative?
Install software as root, eg by invoking sudo.
The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target.
It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.
Install software as root, eg by invoking sudo.
The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target.
It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.
I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently.
[1]:https://news.ycombinator.com/item?id=11772686
[1]:https://news.ycombinator.com/item?id=11772686
I've been meaning to try out Nix for probably years. I work in vfx and large facilities have particular needs that most packaging systems don't support, but there's a huge about of investment that can be leveraged (dependency resolution, caching).
I did a fresh install of macOS with Sierra and decided to use Nix instead of Homebrew this time around. So far I've only started reading through the docs and only have a few things installed; git, vim, tmux. What are your thoughts about using it as a Homebrew alternative?
I've been using Homebrew for years and have been a huge fan so far. I often look at formulas when trying to build things from scratch on Linux.
I did a fresh install of macOS with Sierra and decided to use Nix instead of Homebrew this time around. So far I've only started reading through the docs and only have a few things installed; git, vim, tmux. What are your thoughts about using it as a Homebrew alternative?
I've been using Homebrew for years and have been a huge fan so far. I often look at formulas when trying to build things from scratch on Linux.
If you're considering it for a Homebrew alternative, the main thing is to make a list of all the packages you must have, and then all the ones you would like to have, and then check if they're in Nix. Decide whether you can live with that or not.
Besides that, it's great. The about page sums its features up nicely: http://nixos.org/nix/about.html
Besides that, it's great. The about page sums its features up nicely: http://nixos.org/nix/about.html
>Functionally it's far better
For example?
For example?
The about page sums its features up pretty well, see if there's anything that particularly appeals to you there: http://nixos.org/nix/about.html
Also the HN link in my previous comment has some good discussion of it, just scroll down past the initial Docker comparison thread.
For me the main benefit of it is that I trust it. It doesn't take over system directories like Homebrew, which bugs me even though I'm on a single-user system where that should be ok. Both installs and uninstalls are deterministic, complete, and don't screw anything else up in the system. You can install different versions of the same package side-by-side, which the Debian and Red Hat Alternatives systems also enable, but Nix is more sophisticated about it tagging everything with a cryptographic hash of its build tree. MacPorts and pkgsrc may also provide some of this, but Nix feels more like the git of package managers than anything else I've used, eg the one that finally gets packaging right.
Also the HN link in my previous comment has some good discussion of it, just scroll down past the initial Docker comparison thread.
For me the main benefit of it is that I trust it. It doesn't take over system directories like Homebrew, which bugs me even though I'm on a single-user system where that should be ok. Both installs and uninstalls are deterministic, complete, and don't screw anything else up in the system. You can install different versions of the same package side-by-side, which the Debian and Red Hat Alternatives systems also enable, but Nix is more sophisticated about it tagging everything with a cryptographic hash of its build tree. MacPorts and pkgsrc may also provide some of this, but Nix feels more like the git of package managers than anything else I've used, eg the one that finally gets packaging right.
I know they're different platforms, but how does this compare to apt? Which is better?
Homebrew maintainer view: apt is better.
In addition to this if anyone could compare this apple to that orange and tell me which is best I would be grateful
It's upsetting that Apple doesn't care about developers. Why is there no Apple maintained package management system? This results in having to turn to solutions like Homebrew, which -- while a valiant effort -- is completely insufficient for distributing state across multiple machines.
I absolutely adore Homebrew and can't thank the package maintainers enough. I think of all the times I battled with compiling some package, or installing it via MacPorts only to struggle updating it.
Never with Homebrew. So much <3
Never with Homebrew. So much <3
Homebrew is what keeps me working on a Mac, plus now that Docker for Mac is out....
There is definitely a lot to like about Homebrew (it's better than macports), but like others have said, when stuff goes wrong you can end up spending an entire day googling, only to end up going down a rabbit hole of archaic and often obsolete commands that may or may not work.
Once you get your environment set up it's fine, but try updating to the most recent Mac OS version with a ruby environment and you'll find pretty much all your gemsets broken in one way or another (if you have anything that needs native building).
I might just be bitter, though, as I spent most of a day working through this exact situation just last week.
Once you get your environment set up it's fine, but try updating to the most recent Mac OS version with a ruby environment and you'll find pretty much all your gemsets broken in one way or another (if you have anything that needs native building).
I might just be bitter, though, as I spent most of a day working through this exact situation just last week.
How do I donate?
This is described in the README: https://github.com/Homebrew/brew#donations
A Good Software. Thanks for the hard work, Homebrew peoples!
Of all package managers I use, homebrew is without a doubt the most satisfying. It tracks updates closely and has always had any package I was looking for, yet I don't remember the last time I ran into an error.
(I'm sure all three happen, but if I can't find them with close to 200 packages installed, they must be doing something right)
(I'm sure all three happen, but if I can't find them with close to 200 packages installed, they must be doing something right)
Despite the warnings from their team, as soon as I switched to /opt/homebrew all of my homebrew problems went away.
The biggest issue by far are the number of traditional packages that install in /usr/local with root privileges, thereby clobbering homebrew and making "brew doctor" freak out.
The biggest issue by far are the number of traditional packages that install in /usr/local with root privileges, thereby clobbering homebrew and making "brew doctor" freak out.
> The biggest issue by far are the number of traditional packages that install in /usr/local with root privileges
That is very much a problem with Homebrew, not those "traditional" packages.
That is very much a problem with Homebrew, not those "traditional" packages.
Homebrew: The macOS package manager Apple should have included from the beginning.
Thanks for stepping up.
Thanks for stepping up.
Switch from Ruby to LuaJIT! I'd wager this is the best package manager out there if not for the slowness of Ruby's VM.
Without Homebrew, MacOS would be a lot less a fit as a development machine for me. Thanks to the authors.