Homebrew 1.0.0 | Hacker News Reader

Homebrew 1.0.0

brew.sh

904 pointsrobin_reala246 comments

I've worked with mike to maintain formula for years and he is always pleasant and on top of things in what is a very hectic job.

Homebrew is such a good package manager (and not for the reasons any package manager is classically considered good). It's great because the community is so vibrant, the user experience is so well thought out, and the formula dsl makes so much logical sense. It's actually both a GitHub and Ruby showcase.

Thanks homebrew team! Here to many more years of accessible packages on the Mac.

Thanks for the kind words, Tyler. You've been doing great work for us for a long time so the feelings are mutual.

Thank you Mike and team, seriously. Homebrew is a must have and I can't function on a machine that doesn't have it.

> not for the reasons any package manager is classically considered good

You can say that again. Homebrew's dependency management is a fucking joke, to the point that it might as well not exist.

Honestly, it never seems to be a problem for me and I use homebrew extensively.

That's the reason I stopped using Homebrew and plenty of other comments have said the same thing. Maybe it's changed recently, but last time I used it (about a year ago), dependencies were not cleanly resolved in every case.

What better alternative exists?

Depends what sort of packages you want.

I used to use it for things like local installs of server-side stuff (e.g. language runtime, database server, cache server, etc) but I've moved to using vagrant (and in turn Debian, so Apt) for those things.

For dev tools such as Mercurial, Git, Autotools, etc there are first/third party .pkg installers available.

As a user, Homebrew is a great experience.

As a package maintainer, though, one thing surprised me: you can't make your package depend on a specific version -- even a major version -- of a library.

So if MyApp uses YourLib 1.0, everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors. I have no choice but to drop whatever I'm doing and make MyApp compatible with YourLib 2.0, which may even be impossible.

It's just odd because otherwise Homebrew is so well designed. It seems like a weird omission.

Edit: Some packages get around this by packaging major versions separately (qt, qt5) but most don't.

It's for this very reason that I'm still one of those old-school guys who still uses MacPorts. I was horrified to see this, and in my brief time using it, it actually caused me real problems, so I went back.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google.

[1] https://news.ycombinator.com/item?id=11566720

[2] https://github.com/Homebrew/brew/issues/142

Wow. Thanks for bringing this to my attention. I recently got a new mac and I decided to give brew a spin as my package manager. I was unimpressed with many aspects of the experience- for example, getting weird snarky messages and incorrect advice when I attempted to install texlive- but this seals it.

Back to Macports it is. I'll be sure to tell others about this.

Been using Brew for as long as i can remember. Most of the message usually require a `brew doctor` or `brew update` command which completely fixes the issue. And i cant even remember the last time i had to do that..

When they brought in brew cask i was completely blown away and i use brew exclusively for installing almost everything on my mac.

I tried macports at first, but bailed out of that after i shot myself in the foot inside the hour. Switched to brew and have never looked back since.

i must be the only person on earth that can't get brew to work right.

every so often i'll try to install something with brew, and it just won't work. the last thing i'm trying to do on planet earth is spend 30 minutes debugging a packager on my workstation (as opposed to on servers, where i do this literally all day long), so i just don't bother.

I have never had a problem with homebrew. I think some people like one or the other better as a preference though.

Last time I used Macports, the installation procedure took about six hours of compiling all packages from source (granted, that was an Atom processor). Does it support binary packages now?

Yes.

Yes, official binary archives are available since MacPorts 2.0 in 2011. Due to restrictions by the various software licenses not all are distributable, though.

> following the Google Analytics debacle

I didn't even realize Homebrew was sending my info to Google Analytics :(. I am a huge fan of Homebrew, but they really should make this opt-in vs automatic by default.

Edit: To opt out (the second line is just for confirmation):

    $ brew analytics off
    $ brew analytics

Why would anoyone deliberately bother writing google analytics code in homebrew is beyond me. It should be optin or someone who is sufficiently pissed off could fork it and remove the offending code.

The devs' justification was that if it was opt-in, most people wouldn't do it. They thought it better to turn it on and force users to go manually disable it.

I disagreed in the GitHub issue about this. Debian's Popcorn (package popularity analytics) is opt-in - a choice on install that defaults to "off". That would be the perfect solution. Ultimately those who agreed with me were told that the decision was made and there would be no further discussion - the issue was closed and locked.

was it that hard to just, you know, type "brew analytics off"? Or was there more to that decision?

I've found that a lot of people here in HN and Reddit are really passionate about not being tracked, so even if it was as easy as one command, the fact that Homebrew did it at all is enough to make some people not want to use it.

Nothing wrong with that viewpoint, but I just disabled it and moved on to enjoying pretty good software.

It has nothing to do with how easy or hard it is to disable. The problem is that it doesn't ask first, or even tell you what it's doing. OK, now that I know about it, I can turn it off, but how do I know they won't do something similarly ugly in a future version?

We do tell you about it before we start recording any analytics.

You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.

Privacy violations and user tracking should always be opt-in not opt-out. If nobody opts in, one should rationalize why users may not want to be tracked or have their privacy violated and question whether making it opt-out is a good decision and respectful of their users.

Most people, myself included, never even heard about this before this point, because it's never mentioned as part of the installation or usage process and is opt-out—if you know it exists and that you might want to opt out in the first place.

Actually, at the time I left for MacPorts, "brew analytics off" wasn't an option. Analytics was turned on without warning and without any obvious way to turn it off. They added an environment variable but still left it opt-out (on by default). I disagreed but users who complained were told that the decision was made and no further discussion would be allowed. [1]

> If you feel that way: please use another package manager.

I didn't like how it was handled. I think any sort of analytics, especially by third party companies with real capabilities for correlation and de-anonymisation should be strictly opt-in (off by default).

Opt-in doesn't really hurt users who don't care about privacy and security. Opt-out does hurt users who care about those things. Many organisations have security policies that discourage using software that "calls home". I'd trust the software much more if it didn't have that functionality at all.

The developer's justification was that if it was off by default, no-one would turn it on. I think that speaks volumes about how users feel about analytics these days. Some users suggested a Debian Popcorn style dialog ("We'd love it if you could help us gather some information about package usage, etc etc. Would you like to participate [y/N]", off by default but a question on first run asking the user if they'd like to help). We were told "no".

Overall, I thought it was a bad idea and the situation was handled poorly. For something as integral as a package manager I expect more.

[1] https://github.com/Homebrew/brew/issues/142#issuecomment-214...

I almost went the other way (from ports to brew) because of the complex manual procedure required to fix ports when you upgrade the OS:

https://trac.macports.org/wiki/Migration

After going through the migration, it isn't that bad, but it was surprising (horrifying?) to me that ports was completely broken after an OS upgrade.

MacPorts dev here. Problems can arise when some ports have local patches for specific versions of macOS. This might work at first, but could lead to build failures or other problems later. Some ports also hardcode the OS version into their binaries. The simple way to prevent this kind of stuff is to rebuild all ports for the new platform.

Probably there would be room for improvement, but there is only little interest by contributors. This only happens once a year and after everybody went through it, they quickly loose interest in contributing anything better for the migration process.

"everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors."

Sorry, this is just not true, we hold merging YourLib 2.0 into core until all dependents are upgraded or boneyarded. Maybe you're speaking from your outdated experience with brew years ago.

Also, we do have plans to support multiple versions of libraries, see https://github.com/Homebrew/brew/issues/620 "Handle Versions Better" (although I'm not necessarily a fan of this personally). We also have an openssl@1.1 formula in core already in case you want a sneak peek of the future.

To be clear: I'm only talking about core here. If you try to compile external software against brewed libraries, of course you may run into problems, but we do have the homebrew/versions tap, and you can always host your own taps for outdated libraries.

Thanks for responding. Yeah, my package isn't in core, although it seems I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

I get that it's all a tradeoff, and it must to help keep complexity down if brew is latest-everything.

New versions stuff looks good. I'll look into the versions tap too.

> I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

In core this is true. In your own tap you can vendor your dependencies however you want.

Thanks for trying to support multiple major versions! I run into this problem all of the time with LLVM and its dependencies. I'd love to get have the latest LLVM available for my own work (which depend on the static libraries it builds), but also be able to use tools which depend on older versions of LLVM.

As someone who maintain a ROS installation scheme for Mac based on homebrew (https://github.com/mikepurvis/ros-install-osx), this is a constant source of frustration.

Even a fairly vanilla ROS installation has a deep dependency tree— there are any of several dozen major packages which can at any moment release a new major version and break us.

If you rely heavily on Homebrew in this way you should instead vendor all the formulae you depend on so that updates do not happen without your manual intervention.

Exactly. That's how I managed an app (basically a port of lots of stuff from Linux) for macOS years ago. I depended upon MacPorts as my build system, lots of patching to match our in-house build on Linux... but wrapped an entire Python etc universe inside the app.

That's basically what is done, on a piecemeal basis as things break, but it would be untenable to do it for the dozens of system dependencies, especially when I don't have the resources to set up a whole parallel bottling infrastructure.

In the end, most ROS Mac users still choose an Ubuntu, Debian, or Fedora VM— having a stable set of underlying packages is worth the tradeoff in convenience and performance.

As I've mentioned before: I'm afraid that's a problem for ROS to solve, not Homebrew. We make these options available to you regardless of whether you choose them. Sorry!

Yup, totally understand. I'm looking into Nix and other solutions to see if there might be something else that's a better fit for this use case than Homebrew.

An argument for this approach is that it keeps the ecosystem healthy. Instead of a lot upper version bounds to keep track of and conflicting dependencies, broken dependents are fixed upstream if they don't build. As I understand it nixpkgs, in general, works this way.

This is a valid concern and it's something we're actively working on: https://github.com/Homebrew/brew/issues/620

Few years back when I used OS X I used Homebrew, but also used pkgsrc. It had a few packages that I wanted that Homebrew did not offer. From what I remember it was not a smooth ride, but good enough.

How does Homebrew compare to pkgsrc these days?

Throwback to that one time Google wouldn't hire @mxcl. ;) https://twitter.com/mxcl/status/608682016205344768

Well done Mike and contributors! It's a great piece of work.

He couldn't even ${college_level_gotcha}! No wonder he wasn't hired!

After it has been determined that there is a certain level of capacity to perform, then it should be about how excited they are to learn and integrate into the company's technology stack and culture. Technology stacks have become complex enough in recent years that it is a little bit unreasonable to expect a candidate to be familiar with all of it. The same way it is a little bit unreasonable that the developer would know or remember every college level gotcha you could throw their way.

For instance what if they code in such a way that they haven't run into that problem in years as it is internalised. Or maybe they make use of tools that eliminate a lot of problems, such as TypeScript or similar.

A good developer comes in many forms and increasingly often from all over the world.

According to him. The only context is one tweet from one side of the story.

It's hard for me to understand the issue with this. Google didn't hire the guy who wrote software that had a big impact on the community. Does it mean Google misses good engineers because of their less-than-ideal interview process, or simply Google hires only people who are a good fit for their organisation?

Writing the overly bitter tweet surely won't help with improving hiring points. Seems highly unprofessional and childish.

Well, he's at Apple now in charge of the Swift Package Manager, so I think he did okay.

He left.

Really? I didn't know that. I'm sure he has plenty of options though.

Source?

https://twitter.com/mxcl/status/773573824201699328

Thanks!

Looks like Google was onto something when they rejected him to start with...

Yeah I'm curious why he left. From what I could tell it sounded like changes in Swift took an act of congress basically. Which is fine, and how it should be, given how important it is to get it right. I wonder where he went.

My understanding is he just doesn't really know how to work in a big company.

Meh. I know "how to work in a big company" and choose not to. Talented people will always do whatever they want.

You choose not to, but you could if you wanted to, right? He apparently wanted to, otherwise he wouldn't have gone to Apple in the first place, but he just doesn't know how to work in a corporate environment. In fact, he says as much in this tweet: https://twitter.com/mxcl/status/773574683518119936

You seem to be looking at this through a somewhat unusual prism.

You and I both "know how" to eat discarded food out of a trash dumpster.

But absent some truly compelling reason, we wouldn't choose to do so, right?

That's really interesting. I love homebrew – it does exactly what it says on the tin and I've been using it for years at this point without any reason for complaint. User experience is certainly a part of that, it's very seldom I've found myself in a position where I have to resort to searching for support, since brew usually lets you know right in the terminal what went wrong, and how to fix it. It'll be interesting to see if this great user experience translates to the swift pkg manager.

I will just assert that at Googe scale (some 20000-30000 engineers from a quick search), "good fit" isn't really a thing. Now, it doesn't mean they might not be hiring a certain mono-culture type of programmers, but that might not be a "fit" issue (Disclaimer: I do think "good fit" is vaguely defined)

And I'd love to see a counter assertion/argument.

Is it even possible to have a monoculture with 20k–30k engineers?

Does it mean Google misses good engineers because of their less-than-ideal interview process

Google intentionally prefers false negatives to false positives.

They do have false positives. Quite a bit. They just fool themselves into thinking they minimize false positives by their hiring process.

I'm sorry, but I am sick and tired of "unprofessional" just thrown around like this. The person is a god damned human being, not a robot. They had just gone through an extremely frustrating experience with an unsatisfying conclusion. And it's Twitter.

The only one who's being unprofessional is the one chiding others for being "unprofessional".

I've never publicly called out a company that rejected me. It's not that hard to exercise some self-restraint.

Found the thread: https://news.ycombinator.com/item?id=9695102

After using the terrible piece of software that Homebrew is I don't blame them.

Among all the software I use, Homebrew must be the one giving me the least trouble. I have 100 installed packages and I don't remember the last time anything didn't work. Plus, for anything I care about, updates seem to always take less than a day, usually it's almost instantaneous.

In comparison with MacPorts before, it's like night and day. npm/pip/mix/bundler all seem to periodically conspire to waste a few hours of my time (even though I can do that quite well on my own).

NPM being the worst of the bunch. By a lot. About this much:

`tree node_modules`

The dire status of MacPorts and Fink was the impetus behind Arch OS X back then, but Homebrew's success and ease of use combined with the build-from-source design (it was a real plus not having to host binary packages at the time) preempted that effort.

Some design choices still rub me the wrong way to this day though (quibbles to some, but for a couple use cases it can matter), that's why I'm trying hard to bring back Arch OS X to life.

Anyway, congrats to the Homebrew team! They truly deserve it.

MacPorts started as a build-from-source package manager. The introduction of prebuilt binary packages is a recent addition. It was added only because some packages took a really long time to build.

Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about.

> Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about.

At the time Homebrew rose in popularity it was super easy to add packages to and update existing packages. MacPorts had a reputation, at least, for being inflexible and difficult for casual maintainers. Some not-completely-esoteric packages would not be updated from upstream sources for years.

In my case there was (still is?) the particularly strange case of GNU Octave, in which the development version (octave-devel) had completely superceded the regular package (octave), and this was not really well documented. To get anything done at all with Octave you had to use octave-devel, while octave was essentially a vestigial limb floating around for no reason.

So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem?

I don't think that "tree X" can be a good argument against using any kind of package manager.

It's just popular to hate JavaScript and npm right now.

It's not perfect, but it's not bad either.

This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes for the PHP counterpart. I think it's fine to search for better solutions for our backends, but there is no denying that 1) our browsers rely on JS and will do so for the close future, and 2) that there is an ecosystem for every programming language that can use it efficiently and proficiently.

Yeah, I'm not seeing how "tree node_modules" is an argument against npm per se. Maybe one could argue npm, inc promotes the small-modules approach, but I don't think that's relevant to whether npm itself is a good package manager.

No matter whether you think small modules are good or bad, I personally have experienced npm to at least manage them well. Admittedly, however, I've never actually worked on projects of any great size.

pip is atrocious/dangerous on any system without virtualenv. I've managed to sort this by using virtualenvs where I can and homebrew Python + packages when I can't (numpy, etc.).

Two things really help: pipsi (https://github.com/mitsuhiko/pipsi), which installs tools inside their own virtualenv and PIP_REQUIRE_VIRTUALENV, which stops pip from working outside a virtualenv.

You could try conda. It's basically a pip and virtualenv that works on non-Python dependencies.

That's actually awesome, thanks!

"brew update

Error: /usr/local is not writable. You should change the ownership and permissions of /usr/local back to your user account: sudo chown -R $(whoami) /usr/local

==> Migrating HOMEBREW_REPOSITORY (please wait)...

==> Migrated HOMEBREW_REPOSITORY to /usr/local/Homebrew!

Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with: sudo chown root:wheel /usr/local"

You got to love the user experience of this! Thanks Homebrew team. <3

I see no problem in this. We need writing permissions to /usr/local to finish our migration (as we always did). Once you finish the migration we (hopefully) never write directly to /usr/local again.

I think princetman was being sincere that he loved the experience. homebrew went to the trouble of telling us that we could restore the default permissions to /usr/local, that's nice.

I'm fairly certain you misinterpreted that. He was complimenting the smooth process.

It was a compliment, as mentioned in other comments. I love the fact that it just doesn't error out, it offers a fix right there. It also humbly offers to surrender the rights to directories it no longer need. Coming from recent Dropbox helper agent debacle, I truly appreciate the philosophy behind this and applaud the team.

so smooth. much wow

Sorry, I probably failed to notice the "Thanks Homebrew team. <3" part first time round.

Just wanted to highlight that as of this release, all the core code for Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into the Brew codebase. This should allow for tighter integration between the two and a renewed focus on making installing GUI apps as painless as possible!

From a user/developer perspective, we've created a command line utility (`cask-repair`) to make version bumps as painless as possible. Would love to see more people using it [0], and we welcome suggestions and PRs (we have a few long-standing issues that have gone unaddressed, and fresh eyes are always good!)

[0] https://github.com/caskroom/homebrew-cask/blob/master/CONTRI...

Looking forward to checking this out. One issue I have run into with homebrew is that due to varying packaging choices as a project grows, I've seen stuff move back and forth from brew core to cask to neither, and the old ones stick around at the outdated version so you have to be careful when you tell people to install the thing (seen this happen with terraform for example, which a month ago when I last checked existed as a year-old version in a cask, a few months old version in core, and the current version wasn't available in either).

It might be cool to also allow some kind of process for marking packages as deprecated and showing a warning or confirmation prompt if you try to install it, for the cases when maintainers start packaging in some different way that can't be supported by homebrew.

We do have a `deprecated` caveat, but we rely on users to bring up that fact, as there's no way the maintainers can keep track of the status of every Cask.

There's also a fairly large push and discussion about removing duplication between Homebrew core and Homebrew Cask, so you should see things improve. There should also be Formula -> renamed Cask migration at some point, the issue has been raised in brew-evolution. (We have basic Cask <-> Formula support already).

Re: terraform specifically, looks like it's now in core, and `brew cask terraform` will know to do `brew install terraform` automatically.

Be aware of "update bug"

If Homebrew was updated on Aug 10-11th 2016 and brew update always says "Already up-to-date". you need to run:

``` cd "$(brew --repo)" && git fetch && git reset --hard origin/master && brew update ```

I had to.

Yep, me as well. Thanks!

I also had to do this. Keep in mind that ```brew update``` might take a while to output anything when you do this (it did for me), and then it will ask you to wait while it migrates to a new directory.

Just want to point out that you could always add the --verbose flag to brew commands to see more progress information (in this case how brew calls git to update brew itself and each tap you have tapped, including the core tap).

It took me way too long of daily `brew update`s to notice something was wrong.

it's funny, but other than a few basic tools, most of what I get from homebrew is versionables (nvm, pyenv, etc) of other programming utilities, in that, I don't run brew update very often, usually only before installing something new via homebrew.

Yep, had to too. They released a revision with a broken update fn? Or did they force-push?

Brew is awesome. Note though that it gathers anonymous aggregate user behaviour analytics and reports to Google Analytics, see https://git.io/brew-analytics .

You can opt out with

    brew analytics off

That's a thing they shouldn't enable by default, but I don't mind it. As a developer, anonymous usage data has helped me out enough times.

People! Be nice to your fellow developers! When something asks you to send anonymized usage data, do it!

I disagree. As a friend of mine said, "if you don't trust a software package, don't use it."

I have paid exactly $0 for Homebrew. Reporting usage statistics makes it better, and I'm happy to be chip in to help out.

That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's actually our main use-case for analytics.

Still not a good enough reason for analytics to be opt-out.

> we remove software

Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.

In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

Are the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.

We can make them available on request. Email me.

How did the "royal we" arrive at this "reasoning?"

If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages.

Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.

If projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.

Opt-out tracking is unjustifiable no matter how convenient it may be for the developer.

You could do that with anonymous stats instead of tracking an advertising ID to each user.

Couldn't you just look at the download numbers instead?

We don't host any non-binary downloads so: no.

The fact that analytics are opt-out, not opt-in is my biggest beef with brew.

Homebrew is a huge help that perfectly fills the niche it's intended for. Thanks for all people involved, you're time savers, which is pretty much the most sought after quality of a software project.

Except for loading the Ruby VM. Takes way too long.

Which is why for certain things like `brew --prefix` we now do it purely in Bash rather than using Ruby ;)

Why would bash be faster ? Would not you essentially call the same C lib stuff anyway ?

It would at least save the process-start overhead, plus loading the ruby vm and modules/gems.

Exactly. For a simple string comparison Bash is far faster (although Homebrew doesn't use require any gems, just FYI).

Good to know, so did the speedup come mostly from not spinning-up the Ruby VM?

Yep!

I guess it's a start. But even still, the most basic of commands take a good 1+ seconds on my machine. What about Ruby makes it necessary to use? What is stopping you guys from moving to something like LuaJIT?

Rewriting the entire project in non-Ruby would require a lot of time and create a lot of bugs for little benefit for most users.

Unfortunate.

If Mike is still here in the comments, can you talk a little bit about versioning support? Is this something that's on the roadmap at all, or something that Homebrew has a strong opinion about?

In general, it's a very useful (and pleasant to use!) tool - except for when trying to manage different versions of the same dependency on the same system. Since this is such a big deviation from most package managers, and feels intentional, I'd like to understand why, and whether there is a "homebrew way" of approaching multi-version management.

Thanks again for all of your hard work!

We're working on it: https://github.com/Homebrew/brew/issues/620

I have a stupid question. Is there a dogmatic way of listing installed things and sharing that with other brew?

For example, I now list with brew list into a file and edit the file so that whole list is a big brew install. That way if I reinstall OS or go to another I can have same things.

Don't know if there is but that's a great idea. I always had a pain of brew installing on new systems. Especially when you want to lock versions of some things (MySQL etc).

Not sure if that's what you wanna do but you could do :

"ls /usr/local/Cellar/ | cat >> myInstall.txt"

I just do this for now:

cat <(echo brew install) <(brew list) | sed ':a;N;$!ba;s/\n/ /g' > brew_install.txt

It lists directly from brew, prepends brew install and then replaces all newlines with a space and outputs to brew_install.txt

I use brew leaves instead of brew list for this sort of thing; as I usually don't care about the constituent transitive dependencies, only the final results.

I wasn't even aware of existence of that!

Yeah, I don't know if it's mentioned in the docs. I had written my own version before I found it.

Why not "ls /usr/local/Cellar >> myInstall.txt" ?

I use cat out of habit but yep, you're absolutely correct.

You can use brew-bundle for that. https://github.com/Homebrew/homebrew-bundle

On one machine:

  brew bundle dump

On another machine:

  brew bundle

Well, that's a neat approach!

Thanks to Mike and everyone else that has contributed to Homebrew. I couldn't imagine how difficult it would be managing command line programs on a Mac without it.

I'm wondering if Macs would be as successful with developers without homebrew.

If it wasn't for Homebrew, I would not develop on a Mac.

Mac OS X came out in 2001, and there was a lot of immediate adoption by people using emacs and bash: It became the largest consumer distro of a Unix-based system overnight. (look for all the old articles about how to upgrade from tcsh to bash).

Homebrew was successful because there were developers who wanted it. Is the Mac more successful as a developer platform because of it? Possibly.

It's fun to read all of this. I re-read John Siracusa reviews and some old blogs and yes, until Snow Leopard OSX was THE cool hackers' OS. And when Apple didn't invest in power users anymore, individuals took over.

Thank you Homebrew!

As corny as this may sound. I rely on Homebrew to get my unix experience on OS X and not have to compile everything myself. Saves me time and is one less wrench in my development process.

As a developer, I'm intimidated - Homebrew sets an extremely high standard for software 1.0 release quality.

Remember how long Gmail was "beta"?

The funny thing is how quirky the gmail settings look compared to the rest of gmail these days... it works, but it just doesn't quite fit. Though on the flip side, I don't like how much they changed contacts, and that I can't initiate SMS messages from contacts web ui anymore.

/usr/local was bad but /usr/local/Homebrew is worse.

The best would have been /opt/brew (short, no uppercase letter)

Why is /usr/local/Homebrew bad?

Because the UNIX hierarchy is standardized. System admins only expect bin, lib, etc, share, etc. to be in /usr/local. Imagine deleting /usr/local with the intention of only deleting local packages and accidentally breaking a Homebrew install.

Not to mention it's an uppercase H which breaks UNIX file name convention.

Homebrew is quite an achievement, it grew in complexity over the years, yet remained reliable and kept a user-friendly interface.

It's also very simple to create packages, it took me less 30 min to learn how to create a package and to deploy it. In comparison last time I checked, creating deb packages is absurdly complex, and I usually just give up and provide a Bash file instead.

I find your statement laughable. Brew and Debian's package manager aren't even comparable.

It's easier to create packages for Homebrew but, as I'd be the first to admit, `apt-get` has far more advanced dependency management and resolution. They both have their strengths and weaknesses.

apt-get has a wider scope but, in some cases, what it is needed for is to deploy a simple application, and there's no simple way to do that with Debian packages.

I like brew, but it's complete ignorance of OSX deployment target version (macosx-version-min) means it's useless for building software intended to run on machines other than the developer's. Most commercial software in other words.

I realise that's outside of it's intended feature set, and it's fine for getting dependencies for other people's github projects or whatever. But what I'd really like is the ability to get dependencies that I can feed into my CI system to build software I intend to give to end users.

Thank you guys for making my life as a software dev and end user infinitely easier.

- brew install postgresql

- brew install mpv

The list goes on and on and on. You rock!

Postgres.app[1] would make your life even easier. :)

[1]: http://postgresapp.com/

I switched to use the homebrew version because I couldn't get the pg tools and such to work from the command line. Nobody got time for that. :P

Fair enough, I've personally never had that experience.

After doing both homebrew and Postgresapp for a while, I've switched to using Docker to run it. It's really nice because then on a per-app basis I can have separate versions easily and all checked into version control.

Postgres.app is "easier" to install but more trouble to develop with than properly installed Postgres. And "easier" means downloading an app, since it's quicker and fewer steps to install via Homebrew.

It's a convenient app but I'm very conscious of menu bar real estate, and mostly don't use it for the reason of adding an icon where the only interaction is launching / quitting it.

I wish we had a better GUI for managing a user's daemons on OS X.

Yeah, I'd definitely love to see an option to hide the icon.

It seems like there could be territory here for a menu bar app that hooks into homebrew-services [1]. It'd still take some menu bar room, but it could have one dropdown for a whole variety of services in an integrated way.

[1]: https://github.com/Homebrew/homebrew-services

And you can do `brew cask install postgres`.

From the announcement: Use new Ruby Macho library for reading and writing library macOS Mach O file locations.

Why does Homebrew need to parse Mach-O files? Is this for fixing up shared library paths inside executables?

Author of ruby-macho (the library being used) here:

Yes, exactly. During bottle installations, we need to be able to relocate dylib references and install names so that they're relative to the Homebrew prefix.

I've had few (minor) issues with Homebrew, so I've been wondering about pkgsrc. Has anyone tried using pkgsrc, as a replacement for Homebrew?

I found pkgsrc to to be pretty great, but some of the packages are organized in odd ways and badly named. For example TexLive isn't called texlive. Same with xorg-server. I also couldn't figure out how to install Mac specific variants of things like Emacs. So I'm not giving up MacPorts anytime soon.

Homebrew is really great, and I recently discovered cask (I know, lame, but I'm a MacOS noob :) ) and it's so nice. No more downloading freaking dmg, mounting, dragging, clicking a bunch of popups, no more visiting the app store.

How is this thing not integrated in MacOS yet?

> no more visiting the app store

You answered your own question.

True for Cask, but unless I'm mistaken, cask is a plugin for Homebrew. It is not part of the vanilla install.

That has changed - it's now part of the main project.

Interesting, my bad then :)

Ugh, ugh, ugh. I just tried Homebrew for the third time the other day and it made a complete mess of my /usr/local/bin and also screwed up my install of rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is crufty, opinionated software with poor separation of concerns. Macports is the (objectively?) better choice for my needs.

> it made a complete mess of my /usr/local/bin

In that case you might be glad to hear that in v1.0.0:

> Homebrew’s default repository installation location changed to /usr/local/Homebrew to keep your /usr/local cleaner

Personally, I really like Homebrew and have never had problems (c.f. MacPorts which gave me big problems a few years ago), but I don't use /usr/local for much else, so that's probably why.

Heh, fair enough and thank you, good to know :) Maybe in another year or two my frustration will have abated somewhat. Don't get me wrong, I think it's great that the devs recognized using /usr/local/bin was a bad decision (even if they were kind of forced to because of Apple's SIP).

However -- I just remember, when Homebrew was getting started, all the supercilious (dare I say arrogant?) advice in the docs ... oh, just install to /usr/local, "seriously", etc. (Looking for a reference in archive.org right now ...) Even their whole "Macports driving you to drink?" thing rubbed me the wrong way -- maybe I'm humour-deficient, but I think to criticize another project when your alternative isn't clearly better is just bad taste.

That being said, I am genuinely curious: is there any one awesome thing is that Homebrew does that Macports can't do? Or better, what kind of problems arise from using Macports? I recognize that packaging in Ruby is probably more convenient than in TCL, but other than that? It seems to me that Homebrew is just getting closer to what Macports did (correctly) in the first place. The only way Macports has ever inconvenienced me is requiring a fresh install from time to time when Apple updates their OS, which (for my use case) is minor.

MacPorts isn't without problems, but I can't use Homebrew. Just the message that is printed when you `brew install texlive` is a deal breaker. I don't want to manage packages separately from my package manager, that's crazy and defeats the purpose of a package manager.

Homebrew used to be my go-to tool for installing packages...

But now, with the new Docker for macOS, I never need home-brew anymore. It is especially helpful when you need to run 2 different versions of an app (like elastic search) for different projects.

I can't see myself returning to Homebrew now. That is just not the way to do things anymore.

Apples and oranges. I brew install git, Emacs, jq, and other dev tools. Packaging stuff in Docker is fine, but first you have to create or fetch something to package.

As a side note, Ansible users might be interested in the roles I've been putting together for a bunch of the apps I regularly use [1].

You can kinda use homebrew-bundle in place of some of this stuff, but even then there's random installs that need extra configuration or general mucking about with that homebrew-bundle doesn't give a good way to encapsulate (for example, see the duckdns-updater repo and the template it uses [2]).

[1]: http://galaxy.ansible.com/icopp/ [2]: https://github.com/icopp/ansible-duckdns-updater

There has been a lot of talk in HN comments recently about Homebrew installing to `/usr/local`. With macOS Sierra, the user can no longer write to this folder without specifically owning it. Is there a security risk here and if so, whats the best workaround?

Newer versions install in `/usr/local/Homebrew`, older versions "migrate" there:

http://apple.stackexchange.com/questions/253404/how-does-hom...

Awesome, thanks for that. Would be good for it to be listed on the article. It only tells you that it no longer requires ownership after you have been asked to give it for the migration.

I have a hard time understanding the "migration", even after reading all the related issues. Homebrew still writes into /usr/local/bin and /usr/local/Cellar, nothing different from the past. What exactly changes?

Writing to /usr/local/bin is not the same as writing to /usr/local. We don't drop a README.md in /usr/local anymore, for instance, and you can change the ownership of /usr/local back to root:wheel after the migration.

I've always installed to ~/.homebrew, and never encountered any problems.

Does this mean all your packages are built from source?

I always install to /opt/brew and I see a few packages compile, but I see bottles being used too. Now that you mention it, I guess most software that needs to link against dynamic libraries wouldn't work from bottle unless your setup was the same as where it was compiled... hmm. I don't mind. :)

I enjoyed working and using Homebrew. My first contribution was to bring python 3.5.1 to brew. Loved the processes they have in place for anyone to make a change and have it available for distribution for the whole world using brew on OSX.

Great job for the brew maintainers and contributers. You guys make everyone's job a lot easy!

brew update

brew --version

Thanks for adding the detail I hoped to get from the article

Kersten is a nice name.

Thanks. icantdrive55 is equally romantic ;)

Really what I wanted to. :/

Mine gave me a permissions error, trying `brew doctor` now. I wonder if I have something configured incorrectly from a few years ago.

I do with the update announcement page said how to best update (in case there were any major changes).

brew update --force

(if update errors prevented the migration)

Thanks for this. Didn't work for me due to the "update bug" at https://news.ycombinator.com/item?id=12547579 , but the fix there worked.

In case anyone else command-finded for "update homebrew", this is how you update homebrew to the latest version (1.0.0).

I'm excited about Homebrew potentially coming to Linux. When I first started using OS X more regularly, I was surprised by how better an experience OS X + Homebrew is compared to Ubuntu/Debian repositories + PPAs/third-party repositories.

Isn't it there already?

https://github.com/Linuxbrew/brew

I don't know much about Linuxbrew, but that looks like a fork, not Homebrew officially supporting Linux.

We're attempting to merge the two projects so eventually Linuxbrew/brew can go away. It's a relatively slow process, though.

What about chromebrew [0] (homebrew for chrome os)?

[0]: https://github.com/skycocker/chromebrew

It doesn't appear related so would be hard to merge.

Really? From a user standpoint it seemed very similar.

Either way, I'd definitely be interested in something like homebrew for ChromeOS. Guides for cross-platform capabilities would be most welcome!

I don't use Linux myself, but am curious as to why this has been so heavily downvoted.

Because Linuxes have their own package managers already, and Linuxers are outraged that some macOS freak is invading their lawn with an alternative.

I guess it is because default linux package managers already do a great job.

I personally don't use Mac OS(X), but what I understand is that Homebrew is a project designed to give the functionality of a Linux command-line package manager to OSX.

For most (all? Slackware...) Linux distributions, there is ONE package manager: for Debian/Ubuntu it's APT, for Arch it's Pacman, for RedHat & friends it's RPM, etc. There is exactly one, because all the files which aren't user data or configuration are owned by some package or other. It's all well and good when there's a clear need for this on OSX, and so Homebrew must keep up to date with the official software management and keep itself contained, not breaking anything. Having a second package manager on Linux, which doesn't treat Linux as the main target platform, seems both pointless and asking for trouble.

Alternatively, you could be harsh and figure that the downvoters were saying, "No, you don't prefer Homebrew. You prefer your distribution's package manager, and thou shalt use it correctly."

Ha, thanks that's a comprehensive answer. Maybe have been a bit of both, looks like the downvotes have been countered now anyway.

My issue with those APT on Debian is that I almost always have to add another PPA to download a version of something that I actually want to use. That reduces the utility of APT in my view. Having a crowdsourced list of Homebrew packages to install would be fabulous.

Not only that, but a lot of those PPAs become stale, or get replaced by others, and it's only when you upgrade the dist, that you get failures and discover this... It's pretty annoying. It would be nice to have a meta package manager for "current" PPAs for given projects that wraps apt with brew-like ability.

Additionally, creating and maintaining a PPA involves one of the following:

(a) Use the upload form for Launchpad.net [0]

(b) Host your own deb server [1]

Unless you use Bazaar for a VCS, the only time you login to Launchpad is to upload a new release. With Homebrew it's built into git with adding a new tag. A _LOT_ lower barrier to entry here.

[0]: https://help.launchpad.net/Projects/FileDownloads#Publishing...

[1]: https://www.unixmen.com/setup-local-apt-repository-using-ins...

What don't you like about PPAs? I find them a great experience as both a user and maintainer.

I disagree that they are a "great experience" for users.

Here's my experience with PPAs:

1. Is it already in the Ubuntu / Debian repositories? Nope.

2. Search google for "Ubuntu <package name>".

3. Find some random website like some stack exchange question that tells me what couple of commands to run to get it into my repositories, or risk trying to navigate this disaster of a site.[1]

4. Finally, install the package!

On the other end of the spectrum, (this may be unfair and biased because this is what I"m familiar with), on Arch Linux, to get community maintained packages:

1. yaourt <package name>

2. hit corresponding number

3. answer prompts. (This step gives me the opportunity to analyze the build scripts if I so choose, which includes the source location.)

4. done.

[1]https://launchpad.net/ubuntu/+ppas

Edit: Actually that's not really a fair comparison. I forgot that Arch does not come with yaourt preinstalled. I would have the same complaints about downloading the tarball, unzipping, makepkg, and installing the package on Arch, so take my complaints with a grain of salt. I'm sure it's a good experience with a similar tool on Ubuntu.

My experience is quite the opposite. Lots of missing packages in brew compared to debian. And brew has been nothing but trouble for all the devs in my team. It keeps messing up /usr/local permissions for some reason. And if you don't update brew frequently it will bork itself. Apt-get or better yet aptitude is rock solid.

They are more solid, but never up to date with new bits, so you're stuck managing your own curated list of ppa's.

Apt is as up to date as the repo you point it at.

It's pretty common to use Debian stable and vendor/community repos for specific packages you want more up-to-date packages of.

Why?

By which I mean that apt is fantastic AFAICT and totally integrated into Ubuntu and Debian. Why would you want a third party package manager?

The apt user experience is terrible compared with brew.

How so?

The interface seems more or less identical to me.

I'm not going to deny it's good and brings great stuff to the Mac, I'm just not seeing the advantages.

Other than "in every way possible"?

The only thing that is as easy in apt as brew is installing packages.

Searching, getting info about a package, updating the list of available packages, are all much easier with homebrew.

A reasonable thing to do would be to decide what the deficiencies are and first try to talk to the developers of APT about fixing them, and then as a second (lesser) option potentially deciding to make a higher-level wrapper or supplementary tool which helps these use cases. A totally unreasonable thing to do would be to attempt to replace the entire APT ecosystem with a different tool.

> Searching

apt search ....

> getting info about a package

apt show <package>

> updating the list of available packages

apt update

> are all much easier with homebrew

You gotta be kidding me

Apt is the second worst linux package manager. RPM is the first worst.

`apt` isn't that bad, really—it's been available for a year or two now, and will likely replace apt-get and friends eventually (apt-cache, dpkg, dselect, are pretty horrible user experience really). RPM hasn't been a package manager for like 10 years—now it's just a package format. `yum` and its successor `dnf` are actually fantastic package managers on Red Hat family stuff.

IMO yum is slow as molasses, feature poor and really bad at resolving conflicts. Haven't tried dnf though.

I can see a point in the future where everything is installed via a homebrew-like process.

Forget CPAN, CRAN, ports, pypi, go-get, rpm, apt, cabal, crate, opam, ...

Just get it from github or similar with homebrew.

Doubtful, homebrew doesn't do any kind of dependency management, so it would be a strict downgrade from pip, gem, cabal, etc

Edit: See comment from rogual elsewhere in this thread - https://news.ycombinator.com/item?id=12547076

That's an exaggeration. We definitely do dependency management, we just don't allow formulae in core to pin against arbitrary versions of software because it often means security updates are never tracked. We are going to loosen this slightly but not dramatically: https://github.com/Homebrew/brew/issues/620

Thanks for the clarification. However, if Foo depends on Bar, will homebrew track the dependency so that I can't upgrade Bar to a version incompatible with the existing installation of Foo? I recall running into that issue a while back, and it gave the impression of version tracking being an install-time-only deal.

In homebrew/core and within taps we ensure those cases are handled by `revision`s and CI checks. Across taps this is harder and we're working on it.

Nix kinda does that, we use it for Go, it replaces pip and for system stuff.

Yesterday I was downloading a cask and homebrew told me to update because homebrew no longer needs to own /usr/local.

I think that was a perfect way to be introduced to this release :)

Homebrew has been my "go to" package manager for years! Well done!!

Should I go for a clean install, considering the structural changes?

Should I go for a fresh install, considering structural changes?

Good.

Has opt-out Google Analytics had any help for your project so far?

https://news.ycombinator.com/item?id=11566720

I had uninstalled homebrew this week because it stopped functioning. Out of nowhere, I started getting a ruby error related to a particular package and every CLI call would fail because of it. As someone who works with Go, it's sad to see an error bubbling up and not being gracefully handled.

I had errors with Homebrew and Go this week. In both cases, it was an issue with Websense (also known as Forcepoint). Might your issue be related to that?

Brew claimed it couldn't find the downcase for another package, not Go.

There were bugs in the past few days, but all known ones have been squashed as far as I know, so all you need to do now is

  brew update

at least twice.

Reply on news.ycombinator.com