legacy-homebrew

Found it because I was curious: https://github.com/Homebrew/legacy-homebrew/commit/29d85578e... Here are the comparisons to other package managers: > Packages are brewed in individual, versioned kegs. Then symlinks are created to give a normal POSIX tree. This way the filesystem is the package database. Everything else is now easy. We are made of win. vs MacPorts registry which used its own homebrewed (lol) Receipts files in 2009, and now uses a SQLite DB: https://guide.macports.org/chunked/internals.registry.html#i... > I wouldn't worry about it not being root. We don't install anything base enough for it to be a concern (unlike MacPorts or Fink). vs MacPorts installs to `/opt/local` as root. > Why Not MacPorts? > ================= > 1. MacPorts installs its own libz, its own openssl, etc. It is an autarky. > This makes no sense to me

> brew analytics off The issue is that by default on install Homebrew uses Google Analytics. > And in general it does everything as user not su for a few years now. Homebrew always did everything as the admin user and not as root, and that was always the problem. It mungs permissions of /usr/local; all files, not just directories. And it's not so much of a package manager as it is a needless frontend for git. MacPorts, alternatively, respects default file system ownership, is a full-featured package management system, and like pkgsrc, is based on the FreeBSD ports system. And when uninstalled, MacPorts doesn't leave a mess. With these 3 commands, it leaves no trace (with the exception of the /opt directory in the event it is used for something else): sudo port -vfp uninstall --follow-dependencies installed sudo port -vfp unin

Fun trivia: the original implementation[0] was 17 lines of Ruby, which was absolutely terrible because I didn't know what I was doing. I'm happy to see that it's grown so much! [0]: https://github.com/Homebrew/legacy-homebrew/pull/24107

Here's one I was thinking of: https://github.com/gdm85/coshell The comment about motivation came from a bug report about parallel being "chatty": https://github.com/Homebrew/legacy-homebrew/issues/29060 Nothing homebrew can do about it, of course, but this illustrates one of the implications of parallel doing something unexpected; package managers have to field the complaints.

This page was helpful to me a couple years ago while crafting the tiny PDF used for testing in Homebrew. https://github.com/Homebrew/legacy-homebrew/pull/36606

Dependencies become hardcoded at build time, so any binary 'bottle' whose source package has dependencies that are satisfied by 1+ packages will become hardcoded to just one of those dependencies. https://github.com/Homebrew/legacy-homebrew/pull/41595#issue... Note that the maintainers response was: fuck it, the users can just re-complile this package every time they install it.

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.