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.
> 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.
This mirrors apt from Debian and Debian-based linux distros. "update" simply updates the package index. "upgrade" can be used to upgrade installed packages.
'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.
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.
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?
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`.
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.
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.
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.
[+] [-] dlandis|8 years ago|reply
[+] [-] nullbyte|8 years ago|reply
It's exactly like apt-get update vs apt-get upgrade, if you're familiar with those.
[+] [-] electricslpnsld|8 years ago|reply
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.
[+] [-] throwanem|8 years ago|reply
[+] [-] nobleach|8 years ago|reply
[+] [-] SkyPuncher|8 years ago|reply
`upgrade` will do update plus the actual installation.
[+] [-] sgloutnikov|8 years ago|reply
[1] https://gloutnikov.com/post/control-homebrew-upgrades/
[+] [-] JulianWasTaken|8 years ago|reply
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.
[+] [-] PopsiclePete|8 years ago|reply
One fetches data about what the latest stuff is, what's outdated, new, removed, etc - non-destructive
The other actually performs the operation - destructive
[+] [-] orf|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] tclancy|8 years ago|reply
[+] [-] house9-2|8 years ago|reply
Everytime I need to install an older version of postgres with homebrew it is a no go.
- https://postgresapp.com/
[+] [-] rattray|8 years ago|reply
Link to source for the curious/lazy:
https://github.com/Homebrew/homebrew-core/blob/master/cmd/br...
[+] [-] jhaile|8 years ago|reply
[+] [-] nikivi|8 years ago|reply
I am curious if there is any upside to using it over the hard work brew team is doing.
[+] [-] rebeccaskinner|8 years ago|reply
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.
[+] [-] dhess|8 years ago|reply
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.)
Anyway, highly recommended.
[+] [-] hartator|8 years ago|reply
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] coisnepe|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] junkscience2017|8 years ago|reply
[deleted]
[+] [-] japhyr|8 years ago|reply
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?
[+] [-] mikemcquaid|8 years ago|reply
Yes. I cannot promise it'll be around forever (as I can't promise anything forever) but it remains reasonable to recommend that to beginners.
[+] [-] pfranz|8 years ago|reply
[+] [-] diimdeep|8 years ago|reply
upd: to disable auto update
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] Longhanks|8 years ago|reply
[+] [-] make3|8 years ago|reply
As someone who really likes Python 3, this makes me really happy
[+] [-] JustSomeNobody|8 years ago|reply
[+] [-] sho|8 years ago|reply
Oh man. That is frigging awesome. This is going to save so many people so much time. Where's the tip jar?
[+] [-] draugadrotten|8 years ago|reply
here: https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e9...
[+] [-] andykellr|8 years ago|reply
https://www.patreon.com/homebrew
[+] [-] trebor|8 years ago|reply
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.
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] nerdponx|8 years ago|reply
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.
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] make3|8 years ago|reply
[+] [-] afraca|8 years ago|reply
> 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.
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] smrtinsert|8 years ago|reply
[+] [-] juanmirocks|8 years ago|reply
[+] [-] jventura|8 years ago|reply
[+] [-] mikemcquaid|8 years ago|reply
[+] [-] eumoria|8 years ago|reply
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.
[+] [-] ihuman|8 years ago|reply
[+] [-] mikemcquaid|8 years ago|reply