Homebrew 1.5.0
brew.sh
brew.sh
`upgrade` will do update plus the actual installation.
It's exactly like apt-get update vs apt-get upgrade, if you're familiar with those.
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.
... just to watch his blood pressure rise.
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.
I posit the reuse of nouns from apt would have greatly reduced confusion.
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).
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.
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 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.
One fetches data about what the latest stuff is, what's outdated, new, removed, etc - non-destructive
The other actually performs the operation - destructive
Link to source for the curious/lazy:
https://github.com/Homebrew/homebrew-core/blob/master/cmd/br...
Everytime I need to install an older version of postgres with homebrew it is a no go.
I am curious if there is any upside to using it over the hard work brew team is doing.
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.
(Except for the App Store... no way to manage App Store apps with Nix.)
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.
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?
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.
[1] https://mail.python.org/pipermail/linux-sig/2017-July/000029...
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.
upd: to disable auto update
export HOMEBREW_NO_AUTO_UPDATE=1 export HOMEBREW_AUTO_UPDATE_SECS=3600
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'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 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!
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 someone who really likes Python 3, this makes me really happy
Oh man. That is frigging awesome. This is going to save so many people so much time. Where's the tip jar?
here: https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e9...
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'm glad y'all gave enough warning, but that doesn't make me any less frustrated by the decision.
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.
I think renaming a bunch of packages with a prefix is probably silly, but your response also strikes me as incredibly prescriptive.
I like brew, but I don't like that attitude.
Of course it’s his business! It’s his product and he gets to decide what he thinks people care about.
That’s like saying, “Why did Steve Jobs think it was his business to support mp3 and not OGG on the iPod?”
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.
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.
> 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.
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.