Know what annoys me about Brew? This just happened last night. I had some package that required readline 7.x; Brew uses readline 8 now. It's not possible to simply command `brew install readline@7`. It took me 30 minutes to figure out that I had to cd into the homebrew-core directory, search through github commit history to find an old commit that used readline 7, checkout that specific commit, brew install readline, checkout master again, and then pin readline.
A package manager should not make it that difficult to downgrade a package.
Can't save you your 30m now but `brew extract` should make this process much easier for future.
> Usage: brew extract [options] formula tap
> Look through repository history to find the most recent version of formula and create a copy in tap/Formula/formula@version.rb. If the tap is not installed yet, attempt to install/clone the tap before continuing.
I would at least like to see some mechanism to exclude a Formula from automatic gc of old versions besides brew pin. Libraries don't take up significant space, and they cause a world of hurt to delete out from under compiled binaries, so there is not a good argument for automatically deleting them.
You can also brew install with the Github URL of a formula at a specific version. That simplifies the process somewhat, but yeah, it should be much much easier than this.
The problem with that is, using readline 7 as an example, you need to have had readline 7's image cached on your machine, or it still needs to be 'tappable' or whatever in order to do that. In this case, brew master _only_ had readline 8 available, so if you never had readline 7 installed on your machine, it was inaccessible without bothersome workarounds.
In most cases, brew just works. That's great. But it's also used primarily by developers, and I can't imagine this is an uncommon scenario.
This only works when the maintainers have decided to keep around the old version of the software, which is only done for certain popular formulae. Otherwise they get removed quite quickly from the main tap.
There are older versions of some, usually larger, libraries n brew, such as node@10. But those are maintained explicitly in cases where some other important package depends on them. “Node@10” is really more of a different package than name@version.
this happened to me too. And since brew upgrade now also does cleanup by default, I did not have realine 7 around anymore. No information offerred on how to get it back, just wasted dev time.
I love Homebrew, especially since I (recently) realized I could use brew cask to install all my desktop applications. I liked the analytics feature in this release. Just the other day, I was looking at alternatives to official Chromium builds that would auto-update. I stumbled upon freesmug-chromium but didn't know how actively it is used by the community. Now I know.
I tried to do that for smtg I can't remember. Turns out that it added a lot of deps and compiled the app. I didn't liked it and uninstalled it and brew kept all the deps installed.
It seems it misses an "automatically" installed flag in order to remove the deps I didn't have specifically installed myself in the first place. Would be very great for brew to have that.
Now I avoid trying new apps through brew.
An indication of the formula downloading a pre-built binary or compiling it would be nice too, btw.
> It seems it misses an "automatically" installed flag in order to remove the deps I didn't have specifically installed myself in the first place. Would be very great for brew to have that.
You can use `brew bundle dump` and `brew bundle cleanup` to achieve this (I often do the same).
Automation is great but you're opening up yourself to a security problem by hoping the manifest file is never tainted when you install or update. I can manage to install and update less than 10 non App Store apps without thinking of getting backdoored binary from slipping in at one time.
The argument over the removal of options in this thread [0] is brutal. Very intentionally user-hostile move, repeatedly disguised as being in their overall interest. It left me not feeling very good about the direction the project is taking.
Just don't say how it's a user-hostile move and that you don't feel confident about how Homebrew development is handled, since you will be blocked from accessing the Github repositories.
Is there a more verbose explanation about why they’re moving away from compiling packages from source? All the explanations I’ve seen make it sound like that’s the obvious direction it should go, but it’s not obvious to me.
I got into a minor argument with the maintainers about it, and the response I got was that they thought it was an unreasonable support burden: https://discourse.brew.sh/t/maintaining-a-tap-to-provide-opt.... Not something I could get them to provide more details about, however. Not really a fan of the response I got :/
> We’re not willing to ship things we don’t support, sorry. I do not consider it acceptable to ship software that we are unable to test and we know will break. Even if I did consider that acceptable I’d be unwilling to accept the additional support burden that the maintainers have to take on from people submitting issues when they are clearly told not to (something that still happens often).
Clarification beyond that: fixing avoidable user issues is not what most of the maintainers want to spend most of their (volunteer, mostly evening and weekend) time on. Even immediately closing issues as WONTFIX takes more time to deal with than not getting an issue at all.
You may disagree with this (clearly some people do) but ultimately you cannot expect a volunteer run project to support more than they are willing to do. If we had people stepping up and saying "I will deal with all the support requests for this!" that'd be different but mostly we have people who want us to do the work for them.
What happens to all of my packages I have installed with options? When I upgrade them next they will suddenly be stripped down? ffmpeg is a huge one, as the default set of options excludes many things that most people using ffmpeg need by default, but homebrew can't ship as a binary for legal reasons.
As a user, you can always ask for the package to be compiled from source. This is also what will happen if you ask for non-standard options. The advantage of using binary packages is time: I have a Homebrew formula that takes 40 minutes to build from source, but maybe ten seconds to install from a binary package.
Binaries are built on CI infra with logs that are publicly available and with all the source code doing the builds publicly available. Effectively the same process as local, from source builds. The bottle DSL ensures that the SHA binaries are not tampered with between when they were built (and the source code sha checked) and when they are delivered.
I know this is still a different trust model, but, IMO, not too different.
I know reproducible builds are on the radar for Homebrew in the future, and that should ease some of your concerns too.
Compare to e.g. conda, where you get binary packages and no option to build from source at all. This basically means you get support for x86 and very limited support for PPC. Need ARM? Nope, no can do. Or any other slightly exotic architecture.
It also means, though this is only a problem with third party channels, that it's possible to get into a situation where you can't even build from source at all. I was working with one of our custom packages, where for the life of me I could not figure out how to get the build to work. Turns out it had been hardcoded to run on a very specific machine, and assumed access to a very specific network file system, and I wasted about a week of my life trying to untangle those assumptions before giving up. If that software had been designed from the beginning with the idea that it ought to be possible to build from source from anywhere, we'd presumably be in a different situation now.
Interesting, good to know. I'm guessing third party channel support is probably close to nil though, so for my use case it probably wouldn't get me very far.
You get native binaries, can choose optional features and dependencies and you can easily apply your own choice of patches. That's my view as a gentoo user anyway; I don't know how much of that homebrew actually supports.
Compilers like GCC can produce code specifically for your CPU such that it uses all of the special features you might have like SSE, AVX etc. When binaries are made for general use they have to be compiled with a generic feature set so might not make best use of your CPU.
If you know the exact flags for your CPU then you can compile for it on any other CPU using a cross compiler line GCC, yes. But that doesn't help because in practice you'll just find one binary per architecture, not per CPU.
It’s very useful when on a remote login where you don’t have root but want more modern software e.g. academic HPC clusters with shared filesystems, which tend to have extremely “conservative” OS versions (we are stuck on RHEL6 for the forseeable future).
I’m not aware of much else that fulfills this niche well - conda seems very very tied to precisely tested version combinations, and (from what I remember - tried and had problems) nix seems to want root/system level daemons.
> conda seems very very tied to precisely tested version combinations, and (from what I remember - tried and had problems)
Hello. Conda core contributor here. Do you have any more details? Would love to help.
We try to keep version constraints among dependencies as loose as possible. We do actively patch dependency metadata over time, putting upper version bounds on dependencies when incompatibilities eventually arise.
pkgsrc[1] is portable to most Unix(-like) systems, and can run as a non-privileged user, so that would likely work as well. I'd trust it more than homebrew anyway.
Yes, many maintainers/linuxbrew folk are/were in science/academia. They were tired of logging into HPC system X and needing a certain piece of software. With linuxbrew/homebrew on linux you can just install/build the entire toolchain in user land and get software in your home directory when you don't have root.
I wouldn't recommend it for Fedora since dnf repos are as updated as brew (if not faster) and dep version conflicts are handled better than almost any package manager out there imho.
Yes, I like Homebrew's GNU stow - like capabilities of linking stuff in and out of your environment.
A word of warning, however: Homebrew 2.0 removes your old formula from the Cellar when upgrading. If you want to disable this you must set HOMEBREW_NO_INSTALL_CLEANUP in your environment if you want to hold on to those older versions.
I love brew. But I have heard a lot of complaints against it, and arguments that Nix (and probably Guix) is better. I tried it once, and had a tough time getting my old scripts to find the exact versions. I gave up on Nix. Can someone eli5 why Nix-like approaches are far superior to systems like brew?
Nix is just way more reliable than Homebrew, because it does not use system tools, but rather builds the dependencies by itself (including, for example, a C compiler).
Furthermore, dependencies will not be overwritten if a different package requires the same dependency, but another version of it, so packages don’t break each other.
They opted their users in to analytics (using Google, no less) with disclosure so minimal, most users would miss it. They would not entertain any suggestion that analytics should be opt in, saying that unless you're a contributor, your opinion on the matter means nothing.
They showed a shocking lack of judgement and an abundance of arrogance. I can't trust them anymore. I don't think others should, either.
Well, I for one don't trust Mike after he forced one of the maintainers to resign and then edited his comment on Github and removed the bit where it said "because Mike forced me to resign".
…wow. I don't know what to say; this is pretty egregious. This seems like it came out-of-the-blue; why was Dominyk forced out? Because he made this pull request?
Seems like it's precisely because of that PR. Maybe Mike saw it as a mutiny. But I'm guessing that since he never explained himself in that PR, he's not going to do it at all. It's not like he's unaware of it.
I cannot fully explain this in any public forum without betraying the confidence of things that were said to me in private messages and our private Slack by other maintainers. What I can say is that I do not agree with the claim that I forced DomT4 to resign, it did not come out of the blue, this was the second time that DomT4 has decided to leave the project and all of my decisions were run past other (still active) Homebrew maintainers before I took them.
Important consideration: homebrew is neither a website nor a service. It is a local software, a package manager, and quietly enabling phone-home analytics in an update after previously not doing such has a different threshold for “informed consent”.
How exactly is Homebrew not a service? We donate hours of work each week in an honest effort to make the best package manager we can for our users. Analytics help us decide how to prioritize our work.
It’s also literally the opposite of quietly enabled [1] [2].
Is youtube-dl a service because it needs to be constantly updated, at great effort, to deal with new countermeasures and the like? Still looks like software to me.
If you were running the software for me (e.g. Gmail), then maybe Homebrew would qualify as a service.
> It’s also literally the opposite of quietly enabled
I discovered it when my firewall showed me an outbound connection to Google analytics. Homebrew spews so much stuff to the console, it's not something a regular user would read unless they looked for it. That was hardly sufficient disclosure.
You guys could have prompted for consent. You didn't. You still refuse to. And you won't entertain any suggestions that you do so unless it comes from a contributor. As I said in my original comment, your collective lack of judgement and refusal to consider the opinions of users is why I don't find you guys to be trustworthy anymore. I encourage everyone to find alternatives.
I’m not sure on whose systems you believe packages are built and tested, and from whose systems you feel Homebrew downloads bottles.
> it's not something a regular user would read unless they looked for it. That was hardly sufficient disclosure.
That notice was colored, it was typeset in bold, it was surrounded by newlines, and it sounded an audible bell. Blaming Homebrew for the fact that you missed that message says more about you than about Homebrew.
I don't know what Google does with those packets. Also, I've seen far too many examples of deanonymization to trust claims that data is properly anonomyzed.
When it comes down to it, principle of least privilege applies here. Homebrew doesn't need to phone home to Google to install packages, so it shouldn't.
I didn't know Windows support was on the roadmap. Homebrew has been a critical piece of my macOS toolkit for nearly a decade but I've been working cross-platform more lately so this could be great for me. But what about Chocolatey?
Perfect timing, as I'm setting up a new box today. Homebrew is great. Also really appreciate the inclusion of reasoning behind changes in the release notes.
So far the Homebrew experience has been better for me than any other Linux distribution's package manager, except for Arch, which is still unparalleled. The biggest problem of Homebrew is how incredibly slow it is, though I guess this will stay for a long time unless a fundamental overhaul takes place.
It's a shame it still doesn't play well with more than one user on a system trying to install packages.
I have a work user and a personal user on my laptop. Brew won't let me use both at the same time without getting my hands dirty with creating groups, and even then it's not supported behaviour.
I ended up creating a homebrew user and giving my personal user sudo access to the homebrew user, which has seemed to work well so far (I may have had to give group read/execute access to all of /usr/local though)
I spent a year with Ubuntu MATE after over a decade of macOS use. The thing I missed the most was the hassle free installation of packages via brew. This made me very happy. I hope it will work as friction free as brew on macOS.
I don't know Ubuntu MATE specifically, and it's been a long time since I used Linux on the desktop, but I'm surprised that "apt install foo" has more friction than "brew install foo". Both work very nicely in my experience.
A lot of software that I use weren't available via APT so I had to go hunting via snap, flatpak and pip. Suddenly I had four different package managers to maintain and update. Every time I updated Ubuntu it was a mess to update where what repositories to update to. I was never successful in keeping my software up to date without a lot of googling and problem solving and it sucked.
A package manager should not make it that difficult to downgrade a package.
Otherwise -- homebrew's great.