Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew 4.0.0

brew.sh

Post reply on HN
Print view View original

321–330 of 403 posts

Re: Homebrew 4.0.0

#321

Post by saghm »

mdaniel wrote: post #256
saghm wrote: post #241

Earlier quoted context omitted.

> OTOH building a whole new distribution system instead of effectively git-squash feels weird Or even just `clone` with `--depth=1`? Just because the history exists doesn't mean you have to fetch it.

I wasn't super sure how subsequent `git pull` works with a shallow clone, but if it works the same, then such an obvious fix makes the invention of that API solution even more painful

IIRC, the only thing that will potentially need to be changed is manually fetching the tags, since those won't be brought in. You can just do `git fetch --tags` to get all of the tag metadata though (without actually needing to pull the actual commits they reference; it just gives you the ability to look up a commit hash with a tag so that you can fetch it later).

Re: Homebrew 4.0.0

#322

Post by saghm »

mook wrote: post #282
saghm wrote: post #241

Earlier quoted context omitted.

> OTOH building a whole new distribution system instead of effectively git-squash feels weird Or even just `clone` with `--depth=1`? Just because the history exists doesn't mean you have to fetch it.

I believe they used to do `--depth` but GitHub complained because their systems weren't optimized for that and it ended being cheaper for the servers to send you the whole thing (much easier to figure out what refs you needed, or something along those lines).

I don't know anything about how git servers are implemented, but this is super weird to me. Why couldn't you basically just copy the files (excluding .git), then do `git init`, set the upstream remote, and fetch only the most recent commit? I'm guessing it wouldn't work _exactly_ like that because the git cli is convoluted and nobody remembers the exact semantics of every flag, but it seems surprising that there aren't any possible sequences of commands that do that. Even if they implemented it on server side by just making a "fake" client locally doing this, and then sending the tarball of the repo with just that commit, it would be way more efficient than making clients download the entire history.

Re: Homebrew 4.0.0

#323

Post by misnome »

dividedbyzero wrote: post #188
bsnnkv wrote: post #158

I have a lot of love for Homebrew from many years of using it, but I don't think you'll ever find me using it in macOS or Linux again. I use Nix on both now and I'm convinced that it is the saner way of doing things.

Does Nix still have that extremely steep and high learning curve and huge time invest before you actually grok it? I'd love a Nix that is about as hard to use as homebrew, but no luck so far.

Almost certainly; I still have CC on a ticket from a few years ago that one of the literal steps in the reference manual (teaching --switch-profile) was extremely misleading, didn't work, and actively broke your ability to continue working on nix.

The ticket was closed because the man-page has a technical description of what the command actually does, and people should just know how the command is supposed to work, even if the reference manual tells them otherwise.

Beginner-hostility appears to be baked into the ecosystem.

Re: Homebrew 4.0.0

#324

Post by jljljl »

t8sr wrote: post #67

As an old hand who was around when homebrew started, I feel obliged to let people know there are alternatives. If you find brew's take-over-your-system-and-youll-thank-me approach off putting, and/or you value stability over the coolness factor, MacPorts is still alive and well ( https://www.macports.org ), and in-fact has basically all the same packages brew does. In 18 years of using MacPorts, it's never messed up…

If you're looking for an alternative for creating dev environments, you should check out Devbox [https://jetpack.io/devbox]. Our goal is to combine the usability of tools like Brew or Yarn with the reproducibility and reliability of Nix.

Re: Homebrew 4.0.0

#325

Post by chongli »

woodruffw wrote: post #318
chongli wrote: post #299

Earlier quoted context omitted.

So if a package has a small community of users and is well-maintained upstream but not popular overall you'll keep it around?

Generally speaking, yes: we don't remove things that aren't disproportionately burdensome. You can see that in the yearly analytics[1]: there are packages that only get a few dozen downloads a year, and we don't remove them because they don't cause any issues. [1]: https://formulae.brew.sh/analytics/install/365d/

That's good to hear! I think small, well-maintained projects with loyal users can add tremendous value to a package ecosystem due to the long tail effect. I believe these long tail effects are a big part of the reason behind the staying power of tools like emacs, vim, and LaTeX.

Re: Homebrew 4.0.0

#326

Post by storoj »

afavour wrote: post #243
grugagag wrote: post #164

Earlier quoted context omitted.

Why does it have to be a rate? Failures counts and failure types are good enough to extrapolate whatever else you need

They really aren't. If a package is downloaded 100k times and fails 1k times it's a very different issue than if it's downloaded 1k times and fails 1k times.

IMO installation failures are equally bad, no matter if they happen in 1% of cases or in 100%.

Re: Homebrew 4.0.0

#327

Post by woodruffw »

chongli wrote: post #325
woodruffw wrote: post #318

Earlier quoted context omitted.

Generally speaking, yes: we don't remove things that aren't disproportionately burdensome. You can see that in the yearly analytics[1]: there are packages that only get a few dozen downloads a year, and we don't remove them because they don't cause any issues. [1]: https://formulae.brew.sh/analytics/install/365d/

That's good to hear! I think small, well-maintained projects with loyal users can add tremendous value to a package ecosystem due to the long tail effect. I believe these long tail effects are a big part of the reason behind the staying power of tools like emacs, vim, and LaTeX.

I agree completely!

Re: Homebrew 4.0.0

#328

Post by afavour »

storoj wrote: post #326
afavour wrote: post #243

Earlier quoted context omitted.

They really aren't. If a package is downloaded 100k times and fails 1k times it's a very different issue than if it's downloaded 1k times and fails 1k times.

IMO installation failures are equally bad, no matter if they happen in 1% of cases or in 100%.

Well, you're wrong. If you have 10,000 packages and 1,000 of them are failing it's clearly useful to be able to prioritize which to fix first.

Re: Homebrew 4.0.0

#329

Post by Patrol8394 »

cgeier wrote: post #274
dagmx wrote: post #201

Earlier quoted context omitted.

Well I have bad news for you there too https://ports.macports.org/statistics/faq/ I really do think that people who are concerned about telemetry should install Little Snitch and also look at each of these programs documentation. Telemetry is called out for most of them, as well as how to disable it. It’s also not inherently bad as it can be a valuable tool to improve their systems, though obviously could be abused t…

You need to actively install software to report statistics on macports. See further down the linked FAQ.

Exactly!

``` To start submitting statistics, install the mpstats port in your MacPorts installation.

sudo port install mpstats ```

Re: Homebrew 4.0.0

#330

Post by ComplexSystems »

throw0101c wrote: post #23

On macOS, has anyone moved from/to MacPorts to/from Homebrew? Why did you move? What are the pros and cons of each system?

I switched from Homebrew to Macports, although I may switch back.

Basically, Homebrew will completely crap out on you if you are ever more than two macOS versions out of date. The brew people simply don't keep the older bottles around for those versions of macOS. I think there's a grace period of like one extra version, but eventually they will delete it. Once that happens, your system is hosed if you ever need to install any new packages from Homebrew ever again. You will only be able to install from source, and it's a tossup if that will work.

This is a fairly controversial Homebrew policy and lots of people have complained about it, and there's lots of rhetoric on both sides. My stance: while it's a good idea in general to stay up to date, if you are the kind that likes to keep old legacy machines around to do a few things here and there, you should know your Homebrew installation will eventually break if you don't keep updating the OS. You will eventually not want to do when the system gets old enough, and at that point Homebrew will be a mess.

I'm not interested in the debate as I get both sides, particularly involving security concerns. My experience: simply put, Homebrew's policy will cause you to have to sideline your system, or at least work around this really tedious roadblock, while it still has a good amount of life in it. I wish they kept old bottles around a few years longer, because 2-3 years is not long enough.

So I said that on my current system, which I do keep current, I'm going to not use Homebrew at all. I figured I'd use Macports, since one of the big selling points is that it works on older versions, so I won't eventually run into this problem five years from now. So I did.

The main problem is that there just aren't anywhere near as many packages as there are on Homebrew. Homebrew has become a standard for all kinds of stuff, and if there's ever a package you want on Homebrew, and it's not on Macports, what do you do? You will run into this when using Macports all the time. I've also had issues using Macports with M1; I don't remember the details but there was some weirdness I ran into one point having to configure it to set the architecture correctly on some package I was trying to install. I'm not quite sure how that compares to brew, though, since I haven't tried brew on M1.

So the net result of all of this is, I have a bunch of installation setup scripts that I moved from Homebrew to Macports, and then half of the packages just weren't on Macports, so I had to write scripts to just download those things from elsewhere - GitHub, website installers, whatever.

So now I'm debating moving back to brew. On the one hand, it just has everything, and Macports doesn't. On the other hand, it will eventually break, and Macports isn't that bad - has basic terminal commands I need and so on. I'm on the fence. If there were some user-maintained repository of legacy bottles for brew I'd move back to that.

Post reply on HN