
Homebrew 2.2 - mikemcquaid
https://brew.sh/2019/11/27/homebrew-2.2.0/
======
Athas
While Homebrew is perhaps technically crude and somewhat inflexible compared
to other and older package managers, I think it deserves real credit for being
so easy to add packages to. I contributed Homebrew packages after a few weeks
of using macOS, while I didn't contribute a single package in the ten years I
ran Debian.

I'm also impressed by the focus of the maintainers and their willingness
(really, _enthusiasm_ ) for saying _no_ and cutting features. We need more of
that in the programming field. Homebrew is unashamedly solely for running the
standard configuration of the newest version of well-behaved programs, which
covers at least 90% of my use cases. I use Nix when I want something
complicated or nonstandard.

(Incidentally, I also contributed Nix derivations after only a few weeks of
running NixOS, so Homebrew is not the only good package manager.)

~~~
chrisjc
What are some 'Nix derivations'? I hate to say it, but I haven't heard of any,
let alone used any.

edit: I guess I know lots: snappy, dpkg, apk-tools, etc... I somehow think of
brew as different from this list though. I find myself often wishing that brew
worked on linux.

~~~
patrec
Here's a concrete example:

[https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/elvis/default.nix)

Maybe the three most noteworthy things are:

1\. it's not hard to write your own nix expression

2\. you get a reproducible build

3\. there are very powerful hooks to allow you to easily customize derivations
by various means (look at some more complex derivation, like php, which
defines dozens of options and there are other mechanisms as well).

1\. Brew also has, but not 2 or 3 (it's definitely more customizable than say
debian packages, but much less so than nix)

------
angrygoat
Just ran an update and got this:

    
    
       ==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
       Read the analytics documentation (and how to opt-out) here:
         https://docs.brew.sh/Analytics
    

Opt-out analytics capture? A bit of a shame it's not opt-in.

The fix is to run:

    
    
       brew analytics off

~~~
laurent123456
This is not new, it's been around since 2016:
[https://github.com/Homebrew/brew/commit/1238c65ba14831bc571c...](https://github.com/Homebrew/brew/commit/1238c65ba14831bc571cf01aead8fd10b916c837#diff-
bf4fb942b914c257d474cd2f921e734d)

~~~
blitmap
So it is user-hostile because of data collection, and that the opt-out is not
preserved :-)

~~~
toomuchtodo
It's opt-in because you don't have to use brew if you don't want to. It helps
the devs do their jobs better ( _a job they do for free_ ), and it is a _free_
tool someone is under no obligation to use.

Previous discussion:
[https://news.ycombinator.com/item?id=11566720](https://news.ycombinator.com/item?id=11566720)

~~~
saagarjha
Please don’t subvert the meaning of “opt-in” like this; also, mentioning
“free” does not give you a pass to shut down any complaints about the
software. To address your other points: I disagree that opt-in analytics
necessarily help.

~~~
toomuchtodo
We can disagree on both points. I'm making the effort to defend people who do
real work (brew devs) vs an entitled vocal minority. Time is the ultimate non-
renewable resource, and it shouldn't be wasted by grandstanders.

User hostile patterns should be raised and addressed. This is not user hostile
in my opinion (considering the very little data collected, and the efforts to
anonymize), it is plainly obvious what data is collected, you can observe what
data will be sent, you can opt out of data collection (which the devs find of
value), and you can choose not to use the software.

It has clearly not had an impact on usage of the tool:

[https://formulae.brew.sh/analytics/os-
version/365d/](https://formulae.brew.sh/analytics/os-version/365d/)

~~~
saagarjha
The Homebrew maintainers do real work, but I disagree with your
characterization of this complaint as “entitled” and coming from time-wasting
“grandstanders”. I’d be happy to hear how you disagree but trivializing the
issue doesn’t really help :(

~~~
toomuchtodo
> “entitled”

I think we've reached an impasse. Fundamentally, it's brew's project, not the
user's, and my opinion is that the brew project has met the burden of
attempting to balance their needs (data collection) with those of their users
(privacy). It is very easy to dictate a mandate when it's not your time.
Compromise is necessary, inevitable even.

> "grandstanders"

If someone would like to donate your time, effort, and funds to standing up
analytics infra solely for Brew's use (or perhaps in aggregate for a group of
OSS projects) so that they could avoid communicating with Google infra, I
fully support such efforts. Historically, I have not seen this occur when a
group takes issues with activities of an open and/or free project and the
project has offered to accept the necessary resources from those who desired
to be stakeholders via their input.

~~~
saagarjha
I actually chose to stop using the project and contribute to another one
because I felt that I could not align my values with Homebrew’s and they did
not seem to be willing to compromise on this and other concerns that had been
brought up. (With this specific issue, the “opt-out” part is more important to
me than the “Google” one, so a self-hosted analytics solution would only be
somewhat effective in alleviating my concerns.)

~~~
toomuchtodo
I commend you for aligning your actions with your principles.

------
fouc
Homebrew is built on the assumption that you should always be running the
latest version of homebrew and the latest version of all the packages you've
installed. If something doesn't work, you're forced to update everything to
the latest versions and hope that fixes things.

In general I don't like this constant pressure to abandon old versions of
things, it doesn't really benefit anyone. A fragmented world is a
decentralized world.

~~~
pfranz
I agree, but it reduces the scope of the project incredibly. Freeing up
resources that can be spent elsewhere. Much like how Homebrew doesn't seem to
support multiple users on the same box. It addresses 80-90% of people's need.

I feel like it is less necessary for a user-land package manger like Homebrew,
but doesn't Arch Linux and Gentoo do the same thing with the whole OS? I've
heard of issues, but in general people seem ok with it.

Personally, I've looked to Nix, but went back to Homebrew it after having
trouble with the UI, lack of packages, and learning curve of contributing my
own packages. I'm hoping to try again sometime.

------
exabrial
Man I've been using Brew on Catalina for awhile, didn't realize this wasnt
supposed to work!

~~~
teilo
The only reason it _did_ work was because you did an upgrade. I was also on
the betas. As an experiment, I backed up my Homebrew install and tried one
from scratch. Failed badly. Very important things like gnu-readline would not
compile. I couldn't even get as far as nvim.

Packaging work was already being done under 2.1 to fix what was broken, and
Catalina bottles were already appearing.

By the time Catalina final came out, it was usable from scratch, but only if
you had homebrew installed under /usr/local so you could rely on the
aforementioned bottles.

I was using an alternative prefix of /opt/homebrew. (I have been for years).
When I attempted to continue using that, a few packages for which there were
Catalina bottles would not compile, and so could not be installed under
/opt/homebrew. I finally gave up, and started from scratch under /usr/local.

I REALLY don't like how homebrew insists on /usr/local for stability. The
whole "do yourself a favor" mentality speaks to something broken in their
packaging methodology. Any package should be able to be compiled under any
prefix. And for the most part they can be, except for the exceptions that the
core team or package maintainer doesn't care about because "you were warned."

I wouldn't mind using /usr/local were it not for the fact that lots of other
installers want to put stuff there, and it can cause conflicts. Keeping
homebrew in an isolated prefix makes a lot more sense. /usr/local was and
remains a poor choice.

------
tibbon
I really wish more release documentation pointed you to how to perform that
upgrade. This page, the front page, nor the installation pages show up to
upgrade.

No, it isn't "hard" to figure out, and I personally know how to do it, but for
newer users it puts up a barrier to entry.

~~~
plorkyeran
Homebrew updates automatically when you use it. There's nothing that the user
has to do or to figure out.

------
forgingahead
One of the better package managers out there -- thanks to all the
contributors!

------
ryenus
TIL:

> brew cat sets bat as pager if HOMEBREW_BAT is set

And bat is really a nice alternative to cat.

~~~
Pete_D
Huh, neat. Though I wonder why they didn't just use $PAGER.

------
akoster
I'm just glad Mac OS X 10.13 High Sierra and above are still fully supported
since I have a computer which is stuck on that release (incompatible with
10.14).

------
someonehere
Homebrew + Caskroom has made my zero touch deployments flawless. A little
bash, some DEPNotify, a rock solid MDM, and Apple’s DEP, I can ship a Mac to
any employee in the world and have them boot the computer, create their local
account, and all of the latest third party apps get installed automatically.

Ten years ago this would have taken a lot of engineering. Today it’s just bash
calling Homebrew to do the heavy lifting.

------
xvilka
The problem of Homebrew is the language it's written in. Porting it into
something native and faster, maybe Go, maybe Rust - will make the user
experience way better.

~~~
OskarS
Ruby is not the problem at all. The vast majority of time with homebrew is
spent doing git operations, downloading tarballs, running makefiles, and the
like. You could rewrite the entire thing in Rust and not notice any
difference.

The thing that might make a difference is to build some custom infrastructure,
so that `brew update` didn't have to do a `git fetch` every time, but instead
downloaded the updated formula registry in a more efficient manner. But that's
a lot to ask of a project like this.

~~~
Fnoord
> The thing that might make a difference is to build some custom
> infrastructure, so that `brew update` didn't have to do a `git fetch` every
> time, but instead downloaded the updated formula registry in a more
> efficient manner. But that's a lot to ask of a project like this.

How would this impact privacy? If I do brew search, does that impact privacy?

~~~
saagarjha
Homebrew stores a lot of information in the Git repository that it really
doesn’t need. A simple list of packages would work with the search feature and
probably be faster to work with.

