18 ms·

Homebrew 1.5.0

259 points by mikemcquaid 9y ago

hartator 9y ago
Great work as always, maintening a full packaging system is no easy task, but can you even inverse a binary tree bro’?
- deleted 9y ago
  [deleted]
- mikemcquaid 9y ago
  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).
- junkscience2017 9y ago
  frankly the fact that Google boils your entire resume down to one quiz question is reflected in their product lineup...boring utilities and absolutely nothing new of value to me created in the last five years Google has become Yahoo
- coisnepe 9y ago
  Relevant for those who might not have the reference: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
nerdponx 9y ago
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.
- make3 9y ago
  unless the point is to promote the present version of Python, Python 3
- mikemcquaid 9y ago
  We're unlikely to do that because end-users shouldn't care what language a tool is written in in order to install it.
  - hahainternet 9y ago
    Is what `end-users should care about` any business of yours? I don't mean that insultingly, I mean genuinely. 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.
    - paulcole 9y ago
      >Is what `end-users should care about` any business of yours? 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?”
    - mikemcquaid 9y ago
      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.
    - ncallaway 9y ago
      > 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.
smrtinsert 9y ago
Thanks for all the hard work.
tclancy 9y ago
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.
- jhaile 9y ago
  I also delay upgrading versions just because of the hassle of upgrading the database. This is a very welcome addition!
- rattray 9y ago
  Agreed. Link to source for the curious/lazy: https://github.com/Homebrew/homebrew-core/blob/master/cmd/brew-postgresql-upgrade-database.rb https://github.com/Homebrew/homebrew-core/blob/master/cmd/br...
- house9-2 9y ago
  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. - https://postgresapp.com/ https://postgresapp.com/
diimdeep 9y ago
Homebrew is great, only thing that bugs me is auto update executed before each command, kind of slows down user experience. upd: to disable auto update export HOMEBREW_NO_AUTO_UPDATE=1
- mikemcquaid 9y ago
  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`.
  - benesch 9y ago
    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!
    - mikemcquaid 9y ago
      We've tried and got `brew update` pretty much as fast as we can (at least for the no-op case). I literally added a new GitHub API to make this faster: https://developer.github.com/changes/2016-02-24-commit-reference-sha-api/ https://developer.github.com/changes/2016-02-24-commit-refer... 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!
      - theli0nheart 9y ago
sho 9y ago
> brew postgresql-upgrade-database Oh man. That is frigging awesome. This is going to save so many people so much time. Where's the tip jar?
- draugadrotten 9y ago
  > Where's the tip jar? here: https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e90faac2675aa89e2176d2eec7d8R63 https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e9...
  - sho 9y ago
    Thanks!
- andykellr 9y ago
  > Where's the tip jar? https://www.patreon.com/homebrew https://www.patreon.com/homebrew
make3 9y ago
"On 1st March 2018 the python formula will be upgraded to Python 3.x and a python@2 formula will be added for installing Python 2.7" As someone who really likes Python 3, this makes me really happy
nikivi 9y ago
Has anyone tried to use nix package manager and nix-darwin (https://github.com/LnL7/nix-darwin https://github.com/LnL7/nix-darwin) instead of brew? I am curious if there is any upside to using it over the hard work brew team is doing.
- rebeccaskinner 9y ago
  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.
  - dhess 9y ago
    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.)
  - LnL7 9y ago
    We have a stable channel for darwin now (https://nixos.org/channels/nixpkgs-17.09-darwin https://nixos.org/channels/nixpkgs-17.09-darwin) if you don't want the very latest versions of packages.
    - rebeccaskinner 9y ago
      Thanks, I'll check that out this weekend.
- dhess 9y ago
  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.) Anyway, highly recommended.
japhyr 9y ago
> 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?
- mikemcquaid 9y ago
  > 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.
  - japhyr 9y ago
    Thanks, that's really helpful. And thank you as well for providing something that's helpful to professionals and beginners alike!
- pfranz 9y ago
  I'm also a bit surprised because per PEP-394, the "python" binary will point to python2 for the foreseeable future.
  - RedCrowbar 9y ago
    PEP 394 is not set in stone. There have been occasional discussions on amending it, e.g [1] [1] https://mail.python.org/pipermail/linux-sig/2017-July/000029.html https://mail.python.org/pipermail/linux-sig/2017-July/000029...
JustSomeNobody 9y ago
I love my MBPro. With Homebrew, I love it 10X more. Thank you so much for all your hard work on this.
ihuman 9y ago
I know it's been deprecated, but can I still `brew linkapps` in 1.5.0?
- mikemcquaid 9y ago
  Yes.
dlandis 9y ago
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.
- SkyPuncher 9y ago
  I think `update` retrieves information about the latest versions, but does not actually install anything. `upgrade` will do update plus the actual installation.
- nullbyte 9y ago
  I believe "brew update" updates your package list and version indexes. It's exactly like apt-get update vs apt-get upgrade, if you're familiar with those.
  - _rs 9y ago
    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.
- orf 9y ago
  Its like git fetch vs git pull
  - mikepurvis 9y ago
    Not really, though— git fetch does actually sync you with the remote, so no further downloading is required after git fetch.
- electricslpnsld 9y ago
jventura 9y ago
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?
- eumoria 9y ago
  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.
- mikemcquaid 9y ago
  We support multiple versions with `foo@x.y` packages but we don't support it for many packages or many versions. It's easy to create an maintain these yourself, though: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html
juanmirocks 9y ago
Congratulations to the authors and contributors of Homebrew. Ironically enough, it is one of the most sane Unix package managers, IMO.
afraca 9y ago
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.
- mikemcquaid 9y ago
  https://github.com/Homebrew/homebrew-php/issues/4721 https://github.com/Homebrew/homebrew-php/issues/4721 provides more detail. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.
trebor 9y ago
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.
- mikemcquaid 9y ago
  Any formula that gets removed you can continue to maintain in your own tap (third-party GitHub repository, https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html). https://github.com/Homebrew/homebrew-php/issues/4721 https://github.com/Homebrew/homebrew-php/issues/4721 explains what needs to be done. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.
  - trebor 9y ago
    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.
    - mikemcquaid 9y ago
      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.

Homebrew 1.5.0

259 points by mikemcquaid 9y ago

hartator 9y ago

Great work as always, maintening a full packaging system is no easy task, but can you even inverse a binary tree bro’?

deleted 9y ago
[deleted]
mikemcquaid 9y ago
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).
junkscience2017 9y ago
frankly the fact that Google boils your entire resume down to one quiz question is reflected in their product lineup...boring utilities and absolutely nothing new of value to me created in the last five years Google has become Yahoo
coisnepe 9y ago
Relevant for those who might not have the reference: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

nerdponx 9y ago

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.

make3 9y ago
unless the point is to promote the present version of Python, Python 3
mikemcquaid 9y ago
We're unlikely to do that because end-users shouldn't care what language a tool is written in in order to install it.
- hahainternet 9y ago
  Is what `end-users should care about` any business of yours? I don't mean that insultingly, I mean genuinely. 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.
  - paulcole 9y ago
    >Is what `end-users should care about` any business of yours? 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?”
  - mikemcquaid 9y ago
    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.
  - ncallaway 9y ago
    > 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.

smrtinsert 9y ago

Thanks for all the hard work.

tclancy 9y ago

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.

jhaile 9y ago
I also delay upgrading versions just because of the hassle of upgrading the database. This is a very welcome addition!
rattray 9y ago
Agreed. Link to source for the curious/lazy: https://github.com/Homebrew/homebrew-core/blob/master/cmd/brew-postgresql-upgrade-database.rb https://github.com/Homebrew/homebrew-core/blob/master/cmd/br...
house9-2 9y ago
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. - https://postgresapp.com/ https://postgresapp.com/

diimdeep 9y ago

Homebrew is great, only thing that bugs me is auto update executed before each command, kind of slows down user experience. upd: to disable auto update export HOMEBREW_NO_AUTO_UPDATE=1

mikemcquaid 9y ago
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`.
- benesch 9y ago
  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!
  - mikemcquaid 9y ago
    We've tried and got `brew update` pretty much as fast as we can (at least for the no-op case). I literally added a new GitHub API to make this faster: https://developer.github.com/changes/2016-02-24-commit-reference-sha-api/ https://developer.github.com/changes/2016-02-24-commit-refer... 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!
    - theli0nheart 9y ago

sho 9y ago

> brew postgresql-upgrade-database Oh man. That is frigging awesome. This is going to save so many people so much time. Where's the tip jar?

draugadrotten 9y ago
> Where's the tip jar? here: https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e90faac2675aa89e2176d2eec7d8R63 https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e9...
- sho 9y ago
  Thanks!
andykellr 9y ago
> Where's the tip jar? https://www.patreon.com/homebrew https://www.patreon.com/homebrew

make3 9y ago

"On 1st March 2018 the python formula will be upgraded to Python 3.x and a python@2 formula will be added for installing Python 2.7" As someone who really likes Python 3, this makes me really happy

nikivi 9y ago

Has anyone tried to use nix package manager and nix-darwin (https://github.com/LnL7/nix-darwin https://github.com/LnL7/nix-darwin) instead of brew? I am curious if there is any upside to using it over the hard work brew team is doing.

rebeccaskinner 9y ago
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.
- dhess 9y ago
  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.)
- LnL7 9y ago
  We have a stable channel for darwin now (https://nixos.org/channels/nixpkgs-17.09-darwin https://nixos.org/channels/nixpkgs-17.09-darwin) if you don't want the very latest versions of packages.
  - rebeccaskinner 9y ago
    Thanks, I'll check that out this weekend.
dhess 9y ago
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.) Anyway, highly recommended.

japhyr 9y ago

> 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?

mikemcquaid 9y ago
> 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.
- japhyr 9y ago
  Thanks, that's really helpful. And thank you as well for providing something that's helpful to professionals and beginners alike!
pfranz 9y ago
I'm also a bit surprised because per PEP-394, the "python" binary will point to python2 for the foreseeable future.
- RedCrowbar 9y ago
  PEP 394 is not set in stone. There have been occasional discussions on amending it, e.g [1] [1] https://mail.python.org/pipermail/linux-sig/2017-July/000029.html https://mail.python.org/pipermail/linux-sig/2017-July/000029...

JustSomeNobody 9y ago

I love my MBPro. With Homebrew, I love it 10X more. Thank you so much for all your hard work on this.

ihuman 9y ago

I know it's been deprecated, but can I still `brew linkapps` in 1.5.0?

mikemcquaid 9y ago
Yes.

dlandis 9y ago

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.

SkyPuncher 9y ago
I think `update` retrieves information about the latest versions, but does not actually install anything. `upgrade` will do update plus the actual installation.
nullbyte 9y ago
I believe "brew update" updates your package list and version indexes. It's exactly like apt-get update vs apt-get upgrade, if you're familiar with those.
- _rs 9y ago
  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.
orf 9y ago
Its like git fetch vs git pull
- mikepurvis 9y ago
  Not really, though— git fetch does actually sync you with the remote, so no further downloading is required after git fetch.
electricslpnsld 9y ago

jventura 9y ago

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?

eumoria 9y ago
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.
mikemcquaid 9y ago
We support multiple versions with `foo@x.y` packages but we don't support it for many packages or many versions. It's easy to create an maintain these yourself, though: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html

juanmirocks 9y ago

Congratulations to the authors and contributors of Homebrew. Ironically enough, it is one of the most sane Unix package managers, IMO.

afraca 9y ago

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.

mikemcquaid 9y ago
https://github.com/Homebrew/homebrew-php/issues/4721 https://github.com/Homebrew/homebrew-php/issues/4721 provides more detail. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.

trebor 9y ago

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.

mikemcquaid 9y ago
Any formula that gets removed you can continue to maintain in your own tap (third-party GitHub repository, https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html). https://github.com/Homebrew/homebrew-php/issues/4721 https://github.com/Homebrew/homebrew-php/issues/4721 explains what needs to be done. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.
- trebor 9y ago
  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.
  - mikemcquaid 9y ago
    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.