I'm always so confused by the nomenclature in homebrew. Even beyond all the beer terminology, I'm still not sure what the difference between update and upgrade is. The docs simply defines upgrade in terms of itself: "Upgrade everything with:
brew upgrade". Does "everything" include homebrew itself (which is what homebrew update is supposed to do) ? If so are the commands redundant? It just seems like an example of a great tool overall that has all these unnecessary complications.
However, worth noting that by default all brew commands issue a `brew update` by default before running (so `brew upgrade` is really more like `apt-get update && apt-get upgrade` by default). This can be disabled by setting the HOMEBREW_NO_AUTO_UPDATE env var.
> I'm always so confused by the nomenclature in homebrew. Even beyond all the beer terminology
It is even worse if you aren't a native english speaker. English beer brewing terminology is not part of most language curricula! I enjoy a bit of whimsy as much as the next person, but some precision terminology would suit the toolset better.
It also incenses my French colleague who insists that wine technology is superior to beer technology.
Taps? Casks? Kegs? None of these terms map well to anything. It's like if git used a car analogy and called repos "wheels", commits "blinkers", and branches "exhaust pipes".
Maybe it makes sense to people who brew beer, but I doubt it. It's just cutesy for cutesy's sake, and too many projects do this.
Yes, as a non native speaker this terminology is really annoying. This is funny 2 seconds but should be an easter egg, not part of the real documentation or tool. That’s one more reason for me to stick with MacPorts.
This mirrors apt from Debian and Debian-based linux distros. "update" simply updates the package index. "upgrade" can be used to upgrade installed packages.
Not sure of the parent poster's background, but I think his critique applies to most all package managers. I hop between homebrew, nix, apt, and yum and often have to consult the docs (or guess and hope for a confirmation before anything destructive).
I guess the alternative would be `brew update-local-repository-cache` `brew upgrade-all-packages` `brew upgrade-package vim` which isn't very appealing either. Although, the interface for autocomplete in IDEs have made it easier to use more descriptive names for things (ctrl-D isn't good enough and often isn't implemented or set up for command line tools).
'brew update' will fetch the newest version of Homebrew and all formulae. Upgrade will upgrade the packages. I wrote about this and refer to it when upgrading just in case. [1] It might be helpful.
It's the best we've currently got, but homebrew unfortunately has lots of these rough edges that make it's UX really challenging, yeah :/
Take how, when you have both `parallel` and `moreutils` installed (which still frustratingly ships its own useless parallel and refuses to stop) -- homebrew added a `--without-parallel` flag to moreutils to make them not conflict, but then when you update one or the other, it refuses to update without manually specifying `--force` even though it clearly knows (or should know) that it's safe to do the upgrade.
Or how `brew install`, if there's a bottle missing for your combination of versions, might "silently" decide to jump into a 2 hour long compilation.
> might "silently" decide to jump into a 2 hour long compilation.
You've quoted silently here presumably because it's literally the opposite of silently in that we tell you explicitly what's happening (it's building from source now) and why (the bottle installation failed).
I wasn't trying to be deceptive. I quoted silently to not be deceptive.
I was being liberal in the meaning, not intent -- silently there meant "you do not know whether `brew install foo`" will take 2 seconds or 2 minutes when you run it, and yes I think that's poor UX.
The brew postgresql-upgrade-database command is a fantastic idea. It's not a huge deal to upgrade by hand, but enough of a hassle that I tend to fall behind.
I have gone back and forth between using a homebrew postgres and postgres.app over the years - a few months back I returned to postgres.app and am really liking it, the best part is you can switch between multiple versions of postgres fairly easily (click a button update a symlink).
Everytime I need to install an older version of postgres with homebrew it is a no go.
I try it every few months because I _really_ want it to work locally. Nix itself works pretty well, and most of the packages work well, but there's just enough brokenness in important utilities to keep me going back to brew for now.
It's certainly possible to mix them, and use nix for most things with brew as a crutch until nix packages get better, but I already have the App Store, stack, cargo, pip, gem, and npm trying to manage packages on my system, and I really don't want to add a brew replacement until it can be a complete replacement.
Nix can already encompass stack/cabal, cargo, pip, gem, and npm in a single system. I never need to use 'npm install', 'cabal install' or virtualenv/pip anymore. Nix does it all for me. So if your concern is that you have too many package management systems already, take another look at Nix, as it can probably replace them all.
(Except for the App Store... no way to manage App Store apps with Nix.)
I switched from brew to Nix about a year ago. Nix is, like many powerful tools, difficult to learn, but rewards the effort down the line.
Nix is best thought of as a way of building software, not simply as a package manager, though you can use it only for that if you want (and that is probably the best way to become acquainted with it). So while you can certainly use Nix instead of brew, that is just scratching the surface of what Nix can do for you, if you are in the business of software development or devops. In my view, that is the primary reason to make the switch, because Nix is so much more than just a package manager.
Among the benefits of Nix are:
* Reproducible builds - If you and I use the same Nix expression to build something, each on a different machine, you can be sure that you and I will each produce the same build artifacts (binary executable, library, docs, etc.). [Note - on Macs this is occasionally not true due to "impurities" that creep in from the base OS, but the Nix folks are working to make this a thing of the past on Macs, as well -- see "sandboxed" builds.]
* Distributed builds - Let's say I have a laptop and a desktop. I can configure my laptop to use my desktop as a remote builder for faster builds. This even works for building, say, Linux packages from a Mac. Just tell Nix on your Mac about any Linux hosts where you are also running Nix, and if you ask the Mac to build a Linux package, it will farm the work out to the Linux remote builders.
* "Channels" - You can choose from one of several Nix "channels," where a channel is a subset of the full Nix package set. Some channels are pinned to a specific official release -- 17.03, 17.09, etc. Think of these like you think of Debian or Ubuntu releases. These receive only minor backported version upgrades and security fixes. If you want something more up-to-date, you can run one of the "unstable" channels. These are updated more frequently and may break from time to time; however, the continuous integration server (see below) can give you some guarantees, namely that the packages in these channels will at least build correctly. The unstable channels are equivalent to what some Linux distributions call "rolling releases." (And, if you want, you can just build against the git repo and control your package versions that way, eschewing channels altogether.)
* A community package cache - one of the advantages of reproducible builds is that build artifacts can be cached and used by everyone. The Nix project runs a continuous integration server that builds packages for x86_64, i686, aarch64, and macOS. As long as stay on one of the channels (see above), there is a good chance that your package will already have been built by the CI server, so that your machine can just download the end product and doesn't have to build it. (If you are a Haskell developer like me, this can be a godsend! The CI server builds a pretty reasonable subset of Hackage.)
* Easy package overrides and additions - this and the excellent Haskell support were the main reasons I originally switched from brew to Nix. Perhaps brew has a better story for this in 2018, but overriding packages and adding new ones to the brew package set was not particularly easy when I used it. In my time, it usually involved maintaining your own brew fork in Git. With Nix, it's a simple matter of importing an "overlay" into your Nix configuration. The overlay can modify existing packages, or add whole new ones, with just a few lines of configuration and a Nix expression (equivalent to a brew "recipe," or whatever they call it). Also, I can easily share my overlays with others; just publish it on GitHub and tell someone to import a single file from that repo into their Nix config, and they will see the same package overlays as I do. Finally, overlays are composable by design, so you can combine them from multiple sources to create a single package set tailored to your needs.
I could go on, but I'll stop there. Oh, except to mention that cross-compiling support is coming very soon, so that you will be able to build packages for, say, armv7l-linux on your very fast x86_64-linux build server. If you do embedded development like I do, this is huge. When this work is finished, I believe that only Debian/Ubuntu will have a similarly compelling cross-compiling story (minus all the other benefits that Nix brings, of course).
Interestingly, though my initial motivation for the switch from brew to Nix was to use it as a package manager, one year on that is easily the least of the benefits I've derived from learning it. It has completely changed the way I build and deploy software and Linux hosts. (I have not mentioned here NixOps, because it is not relevant to Macs, but if you do any kind of Linux deployments and you are using Nix, you will probably want to at least take a look at NixOps.)
Worth noting that was the creator of Homebrew rather than the post author/a current maintainer (I say this as I don't want to take any credit for creating something I didn't).
> We will maintain python2, python3 and python@3 aliases.
Is the python3 alias likely to be present indefinitely?
I work with beginners a lot, so I look for a simple installation with as few steps as possible. I like that someone who hasn't set up their mac for development can run 'brew install python3', and then use the python3 command to work with the latest version. They don't have to modify their PATH to get started, and as long as they use python3 to run programs and configure a text editor, they don't have to think much about the difference between their Python 3 installation and the system Python.
I understand that 'brew install python' will now install Python 3, which is great. But that does mean you have to modify your PATH to have the python command use the homebrew-installed Python 3 interpreter, right?
Is it reasonable to continue to recommend that beginners use the 'brew install python3' command?
I probably should have linked to the PEP in my comment, because you're right, it says right in the PEP it can change in the future. I would just expect the PEP to change before package managers.
I would think it would be confusing to install a package called "python" and have to run a binary called "python3" while a package called "python@2" installs a "python" binary. But anyone learning Python in the foreseeable future will have to deal with 2v3, anyway. Personally, I'm more likely to reach for Homebrew to install Python3 since macOS ships with 2.7. However, if macOS does ship Python3 I'll probably reach for Homebrew for Python 2.7.
Thanks! Consider setting HOMEBREW_AUTO_UPDATE_SECS to a high number instead. For example I set
export HOMEBREW_AUTO_UPDATE_SECS=3600
In case you're wondering the reason we have auto-update on by default is because before we did literally ~50% of our issues were solved with a `brew update`.
My biggest frustration with the auto-update is how long it takes. I wouldn’t mind the auto-update in the slightest if it took 5s instead of 30s. It’s ironic (and a testament to your work on bottling) that the longest phase of installing a formula, even one with many deps, is waiting for `brew update` to complete.
I’m curious if you have plans to make `brew update` faster. Is it really just `git pull` that’s that slow?
Apologies for griping. Homebrew has made my life much, much better—thanks for all your hard work!
Would definitely welcome any help making this faster, though!
> Apologies for griping. Homebrew has made my life much, much better—thanks for all your hard work!
I wanted to particularly highlight this part of your comment: stuff like this is really kind, not common and really helps with my motivation to work on Homebrew. Thank you too!
> I wanted to particularly highlight this part of your comment: stuff like this is really kind, not common and really helps with my motivation to work on Homebrew. Thank you too!
I'd love to chime in while we're at it. Thanks Mike, for your awesome work on Homebrew. My life is significantly better because of it. I remember back in the 2000s how I would literally spend hours at times figuring how to fix compilation errors, Googling for undocumented CFLAGS, etc. Homebrew is such a pleasure to work with, and it feels like it just keeps getting better. I have no idea how, but it does.
Less time spent tinkering with build flags means I get my work done faster, which means less time working and more time with my family. You rock.
UPDATE: Just set up a $10/month contribution to you folks on Patreon. Here's the link for anyone else who's interested in contributing: https://www.patreon.com/homebrew
I would like to chime in as well :). Homebrew is and has always been awesome in my exerience. Besides just working all the time, I love how extendable it is by providing your own taps. For example, I use railwaycat's emacs-mac tap. Thanks to Homebrew mituharu's Emacs version is just two commands away.
I also regularly just local software in /usr/local/Cellar/<name>/<version> to be able to use brew link/unlink et al. to manage symlinks.
Keep up the great work!
Ps. I just noticed that it's possible to donate on a non-recurring basis now as well. Great!
apt-get update just took 15s on my Debian to finish. The thing is, I actually never run apt-get update, I just have a cron job which runs it before installing security upgrades.
Ideally homebrew would be faster, but in the meantime you could run updates in the background regularly enough so that you never have to do it while running a brew command interactively (if you use the parameter that has been suggested).
As a PHP developer, merging the PHP repository into core will be disastrous for me. I have 27 packages installed for PHP 5.5 - 7.2, and the versioned extensions will evaporate. So much of my tooling is built around homebrew and the `homebrew/php` tap, that my entire toolchain for development will change.
The last time, Apache was switched from installing/running at the system level to user-based. That broke almost everything on my system for a day while I tried to fix it. Worse, there wasn't a warning prompt before the package upgraded.
I don't have time for things to break down every 6-12 months.
I understand that. However, if I had time to contribute to homebrew, I would have by now. I definitely do not have the time to maintain a tap and keep its packages up to date.
I'm glad y'all gave enough warning, but that doesn't make me any less frustrated by the decision.
Sure, I understand your frustration. Similarly I hope you can see that it's frustrating for us when we make it very easy for people to help themselves and they don't try to do so because they are too busy. You have a job, we have jobs and most of Homebrew's work happens outside people's jobs.
If I could make one request, it would be that Python formulas get a "python-" prefix, PHP formulas get a "php-" prefix, and so on.
There are still some things I don't love about Homebrew but there is quite a lot that I do love. Thank you for continuing to build great software and maintain a high standard for packaging. The binary "bottles" are especially appreciated.
Homebrew is a package manager for macOS, not language libraries. I know there is a bottle for Numpy (and I'm sure other libraries as well) but I'd suggest not co-mingling your OS and Python package managers.
Homebrew really shouldn't ship libraries in the first place, for that we have our own language's package management (and for cases where we have difficult to install binary dependencies, we have our own language's mechanism for dealing with them).
Language package managers are for developers. End users should use their platform's package manager to install whatever libraries their application needs. E.g. Apt knows what version of numpy easypaint works with, while pip simply gives you the most recent.
Downside: numpy, h5py and others use an embedded libhdf5 which is quite outdated. Meanwhile, homebrew has the current version, but they ignore it. In contrast, the Debian/Ubuntu/FreeBSD ports have python packages built against the packaged libhdf5. The pip packaging is inferior to the properly packaged stuff, which is what you get when language-specific packaging exists in its own isolated bubble.
I feel like the correct move here is to push the library maintainers to update to the new version. Distribution package mods should really be seen as temporary.
I have already opened an issue for this. However, it doesn't resolve the underlying and rather harder to fix problem of different language-specific package managers embedding copies of C and C++ libraries which can end up in a horrible incompatible mess. It's not specific to pip/pypy, it also applies to Java jars with embedded libraries and other systems which also embed.
Sometimes, this embedded copy can be more up to date than the system copy, but the convenience of embedding is often outweighed by the binary compatibility problems and being neglected and out of date.
Given we're a tool that exists primarily to save time for our end-users I'd like it to be optimised so they don't need to care or think about things like what language a tool is written in to be able to install it.
> Is what `end-users should care about` any business of yours?
I only wish more software held a laser focus on what end users wanted, and thought about their needs as a top priority when evaluating proposals.
Brew is a really awesome piece of software to use, and it's that way because the authors are clearly constantly thinking about their users when they make decisions.
It's slightly unclear to me what will happen for the php formula's, we have several people working very happily with it, easy to switch between major versions and include extensions.
> By 31st March 2018 we will deprecate and archive the Homebrew/php tap. Unfortunately we have been unable to maintain an acceptable, consistent user or contributor experience and CI workload through non-core formula taps in the Homebrew organisation so we are continuing to migrate widely used formulae into Homebrew/core and encourage more niche formulae and options to be supported outside the Homebrew organisation.
One thing that I don't know if it's possible with homebrew is installing previous versions of packages. For instance, brew install python3 installs python 3.6. How can I install python3.5?
Some uses in apt will have python3 then have python3-3.4 subdivision but usually that's because an update broke something and it's usually removed when the issue is resolved (also this is distro specific)
I don't know if brew does anything like this however, but I know in the apt environment that's usually how multiple versioning is done.
