legacy-homebrew

It's an acknowledged problem with binary distributed packages: https://github.com/Homebrew/legacy-homebrew/pull/41595#issue... Homebrew is more like home made bread that's taken out half way, because it's half-baked and basically terrible. First they rely on end user compilation for everything, then they support distributing binaries in a way that's as smart as a brick.

Except the dependency management solution is terrible, unless you want to compile everything yourself. For example: https://github.com/Homebrew/legacy-homebrew/issues/35995

Not only that, but an hour after your post, someone (burma-shave) had updated the LFE formula for v1.0 of LFE: * https://github.com/Homebrew/homebrew/blob/f95c192d43d9a56bda...

Hello! I'm the Homebrew maintainer and GitHub employee who wrote this. The main thing this API does for Homebrew is make no-ops really fast for `brew update`. As you point out this results in no speedup (in fact a tiny slowdown) for the case where you only run it where you know you have changes. Where it becomes useful is if you are using multiple taps (Homebrew's 3rd-party repositories) which update infrequently or if you want to run `brew update` automatically in e.g. a project bootstrap script that's run frequently. In the medium to long-term I'd like to consider Homebrew running `brew update` automatically before you `brew install` (https://github.com/Homebrew/homebrew/issues/38818). For us to ever be able to do that `brew update`'s no-op case needs to be extremely fast.

I noticed recently that there's an open PR for Homebrew to add a formula for MLTon. There are still a few glitches to be ironed out, but I'm really hopeful that they can resolve them. I've been using SML/NJ locally for schoolwork, but it'd be really nice to have an easy-to-install, full-fledged SML compiler with top-notch performance installable with just brew install mlton [1]: https://github.com/Homebrew/homebrew/pull/48694

> At least on OS X, things are a little easier with Homebrew. Absolutely. I adore Homebrew and it's ecosystem. Cask, in particular, is quite satisfying; gotta love installing a swath of neccessary fonts from the terminal. And, fwiw, the project is about to be on Homebrew, with no tap required: https://github.com/Homebrew/homebrew/pull/49040 Though getting it up was not quite as pain-free than our initial publishes to NPM. The thing is: Homebrew solves the problem for just a portion of your audience. In diff-so-fancy's case, we've supported Linux and Windows from the get-go, the only hard part is getting it installed. NPM solves that problem really well, and I can't imagine any other installation technique being our recommendation for Windows/Linux going forward.

> when a post on better diffs showed up on Hacker News > last week ... people below are asking why a bash script > (that depends on a perl script) is being recommended to > install via NPM? [cont. about using Homebrew] This post is useful in general, but just to circle back on its motivation, for anyone wanting a non-npm (brew) install of the aforementioned diff tool (diff-so-fancy, not made by me) - I've a PR pending merge - Homebrew/homebrew#49040 [0]. In the mean time, you can tap it: % brew tap OJFord/formulae % brew install diff-so-fancy [0](https://github.com/Homebrew/homebrew/pull/49040)

Looks like two^Wthree people have already raised PRs for getting version 2 in Homebrew[0] [0] https://github.com/Homebrew/homebrew/pulls?utf8=%E2%9C%93&q=...

Hopefully soon: https://github.com/Homebrew/homebrew/pull/48460