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.
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.
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 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.
"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.
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.
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.
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 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):
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.
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, official binary archives are available since MacPorts 2.0 in 2011. Due to restrictions by the various software licenses not all are distributable, though.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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)
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".
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.
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:
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.
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.
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
==> 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.
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.
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.
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!)
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.
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.
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).
Brew is awesome. Note though that it gathers anonymous aggregate user behaviour analytics and reports to Google Analytics, see https://git.io/brew-analytics .
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.
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.
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.
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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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]).
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?
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.
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 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!
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.
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.
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.
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.)
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.
`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.
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."
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.
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.
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?
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.