This is awesome. I've been wanting something like a "brew browse" command for a long time to see what popular tools I should consider trying out. I'm probably going to spend the rest of the night googling everything I don't recognize on the most installed list.
Anyone have any suggestions for things to look at first?
>Neovim is about as popular as emacs now (backhanded compliment?).
I'm primarily an Emacs user. The homebrew provided one kinda annoying. https://emacsformacosx.com/ is better.
If you serve bad ice cream but decent hot dogs and your hot dog sales numbers are higher than ice cream's, you can't generalize that to "people like hot dogs better than ice cream."
I'm curious. The homebrew formula seems to just download emacs from the main GNU repository. So what makes emacsformacosx better? The website doesn't seem to explain this.
One thing it gives you out of the box that is difficult with the other Homebrew options (there is also https://bitbucket.org/mituharu/emacs-mac/overview) is a standard macOS application that you can launch with Spotlight.
If I remember correctly, one of the developers of GNU Emacs removed Mac-specific functionality as GNU doesn't want these type of patches in the software that they release as it goes against their core ethos.
OS X also ships with a vim installation that can't access the system clipboard (I mean specifically "+; needing to type :set paste ⌘V :set nopaste is a PITA). This annoys me quite often.
(And replacing the built-in vim, if you also want to have mvim, requires passing special flags to mvim that require you to have an Apple account.)
Walk in any Rails developer office and look at the words written on the whiteboard - you never know if it's a list of gems or a they're having a schizophrenic episode
Yay more words and concepts to add to my cognitive load. We already have established terms for these things but why use package and repository when you can invent tableturd and puddlecuddle?
When it comes to UI it sometimes feels like programmers go out of their way, to make software get in mine.
I'll take it, but I'll keep rolling my eyes and sighing. -.-
Yea, I agree, I thought it was cool/clever to start out with but I have to reference the jargon when I revisit modifying formula or making bottles, usually there is a long enough hiatus from messing around with homebrew that I forget.
Some terms are useful if they're unique. Which is easier to remember: a uniquely named directory called `Cellar/`? or another `bin/` somewhere in the filesystem?
>Yay more words and concepts to add to my cognitive load. We already have established terms for these things but why use package and repository when you can invent tableturd and puddlecuddle?
Why volunteerily start, develop, and maintain a package manager and its repository, if random people are gonna try to dictate even how you name your packages?
A "keg" refers to the whole directory structure associated with an installation. A "bottle" is just a tarball containing that structure from a build on the CI, rather than a from-source installation.
It makes sense but, like you said, you're exhausted and don't care.
Bottles (binary installations) are an addition to Homebrew; it was originally a source-only "package" (really just Ruby scripts that downloaded tarballs and ran `make`) manager.
Terminology is important. However, the standard terminology of package management does not always map cleanly to Homebrew's behavior. If the options are inventing our own terms or using preexisting ones unlike everybody else, I'll always go with the former.
Edit: I'm mostly thinking of things like "keg" and "bottle"; "tap" could indeed be replaced with "third party/external repository", and a "formula" could be called a "package description" or something equally generic.
Grep and awk were a new thing decades ago. I expected we knew better now, but, it seems, we are doomed to ignore the past and go reinventing (and then having to fix) our own square wheels.
I've always used Macports, quite solid. Also, the whole "screw Google because they wanted me to know a basic algorithm" drama was off-putting for various reasons.
This seems to be a common problem with Ruby projects. fastlane.tools is incredibly popular for automating iOS development. "gym" is the subcommand to build an app, "scan" runs tests, "sigh" fixes code-signing etc.
There seems to be sizable chunk of people who agree (myself included).
At this juncture (1.2 and rather successful) is there any feasible way for the maintainers to switch the nomenclature to something a tad more literal/expressive?
I agree that the jargon needs improved. The hard balance is figuring out natural names for things that don't make things harder for existing users to understand.
I love brew! But just be careful because it has a tendency to be unhelpful with its updates. Same thing with cask. That's the way they do things, and I understand that it makes sense for them.
For example, I wasn't on El Captain yet, so I had to checkout an older version of openemu.rb. It seems like this would be something that could be automated, and if I had time, I might.
Inspired by Tigerbrew[1], I was actually thinking of making some sort of "LTS" tap, which has stability and predictability.
An LTS tap is a great idea. We can't support older versions of some software, unfortunately, just because we're limited in resources but everything should be there for you to be able to do so yourself.
But I do think that the various taps and casks and sprockets and bits are potentially getting out of hand. Homebrew 2.0 - New API and usage pattern?
However:
cask outdated: Finally! Thank you!
search: Updates most welcome.
And plenty of others. Thanks for all. And one tip:
export HOMEBREW_NO_AUTO_UPDATE=1
That saves me no end of time and irritation on slower networks. And on faster networks, too. I don't want auto-update on by default, but if it has to be, so be it. There's the fix.
We'll see what happens but if it's up to me Homebrew 2.0 with a new formula API will never happen. Yes, we have a bunch of cruft that we could kill but breaking all existing formulae (particularly 3rd-party formulae) seems like a price not work paying.
Similarly, if you find auto-update helpful but it runs too often check out `export HOMEBREW_AUTO_UPDATE_SECS=300` which would bump the check time from 60 seconds to 5 minutes.
I just saw that Homebrew has a Patreon page. I use brew everyday and want to make sure they stick around. I encourage others to support the project as well:
What's the status of the relationship between Homebrew and Linuxbrew? I remember a while ago there were discussions about making the two systems more compatible (or even merging them?). I'd love to see Homebrew take off on Linux.
We're gradually trying to merge the package manager parts of the two projects. Fun fact: Homebrew/brew is now used on Linux for uploading our binary packages, it's just missing various user experience tweaks that Linuxbrew provides. We'll get there!
It's not yet the production tool that Homebrew is, but there is Spack: https://spack.io, which allows installing arbitrarily many builds of a package, with different versions, compilers, and options (disclaimer: I'm the original author).
Correct. We've made it easier to install some old versions of some packages (the most popular, basically). We don't have the resources to support all old versions of all software; many old versions simply won't build on modern versions of macOS/Xcode.
I used to install everything on my Mac through Homebrew if it's available on Homebrew, but recently I found myself starting to moving away from Homebrew.
First it's Go. Go installed from Homebrew lacks the source code, so I cannot ^] into a standard function's source code in vim-go. So I did `brew rm go` and installed the pkg version instead.
Then the recent rust update had some problem building in Homebrew, and I discovered that the rustup tool is actually very nicely done, so I did `brew rm rust` and used rustup instead.
I've been using Homebrew for a few years now, but I've gotta admit that recently I've been intrigued by MacPorts. Can anyone that has tried both extensively share their thoughts, and possibly explain why they're using one or the other? I read up a few comments online from having googled around, but I'd love something more recent.
One of my complaints with Homebrew (and most system package managers) is that it treats all dependencies as equal. If I install X, which depends on Y and Z... I'd expect Y and Z to be removed when uninstalling X. If anyone else is frustrated by this, I'd suggest checking out homebrew-bundle [0]. The idea is simple: you create a Brewfile and you use that to track dependencies. Instead of installing stuff from the CLI, you add entries to your Brewfile and run "brew bundle --global". Sadly it won't do any automatic cleanups, so you have to run "brew bundle cleanup --global" to get a list of extraneous packages and remove em manually.
Another obvious benefit to using a text file is that you can annotate it with reminders. "What did I install this foobar tool for?"
I think migrating towards a shell environment which gets configured using idempotent scripts can help reduce bugs and lower the barrier of entry to people less familiar with the ecosystem, as well as make it easier to get your own system up and running. In the last few weeks I started toying around with nix [1], which seems to promise that... Although I'm still finding my way through their ecosystem.
I'd like to think I'm a fairly pragmatic user, so I'm willing to accept some hacks here and there. A few days back I put up a repo [2] to show what my macOS + fish shell setup looks like. It won't track configs to clean-up garbage or anything fancy like that, so if you make any change you might need to clean up manually. But it should make bootstrapping a new system a bit easier, and it encourages you to configure all universal variable definitions in a single place so you can add notes for why you're doing whatever it is you're doing. One of the biggest benefits of maintaining an idempotent fish config is that it has great performance. Since fish shell persists environment values in a single file and it lazy-loads function definitions, starting a new session happens almost instantly.
I switched away from MacPorts because packages I cared about were consistently out of date. For example, the MacPorts package for Pandoc is 3 year old [1][2]. That's a cherry-picked example, of course, but was representative of my experience at the time, and appears to still be true. In contrast, the packages I've found on Homebrew have generally been up-to-date or close to it.
Your milage will of course vary, and I suspect that more popular packages are probably updated much more aggressively.
Did you consider submitting a patch? In the past I've submitted patches and kept my own portfile in the mean time (seems quicker than replacing an entire package manager).
Honestly, no. If I were in the same position today, I would do so. I have submitted patches to Homebrew, for example.
In my defense, the Homebrew project is much more upfront about user contributions, and I think that's a big part of why they get them. It's literally right on their homepage:
> It's all git and ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates.
> brew edit wget # opens in $EDITOR!
This does two things: (1) it demystifies the package format and makes it sound like something that's easy to get into, and (2) the presentation in general seems much more welcoming and positions the project as one which is open to contributions.
In contrast, I've messed around with packaging on Debian, and my experience there was that there were much higher upfront costs to contributing, precisely because there was so much more tooling around the system. As an example of what I mean, try taking an existing Debian package (like, say, PHP), and rebuild it with different compile-time flags. It's a lot of work to figure out how to do that!
I'm not in a position to say whether the ports system and MacPorts are anything like that, but I do have to wonder if (as representatives of a more traditional era of packaging) whether they suffer from some of the same burdens.
I've used both homebrew and macports recently. Both are fine, but I do prefer macports. I like the way it tracks dependencies. Yes it takes a bit longer to install packages because it likes to install its own versions of everything, but that really hasn't been a problem for me. I suppose it would matter if you needed to set up a new laptop on battery power using crummy public wifi, but otherwise it isn't a big factor for me in picking between the two.
Homebrew does have the cask system for installing apps and fonts. It is useful for grabbing things quickly, especially stuff like the oracle jdk and vagrant which use package installers. Still, anything you install with cask is going to self-update, most likely, rather than providing updated through homebrew, so it is really a one time benefit.
I strongly agree with using Homebrew Bundle in this way. Apologies for the self-promotion but I wrote a post about how I used this combination at GitHub to replace our use of Boxen. Works great for having Homebrew dependencies be project-specific (if still installed globally):
I used Macports but now use Homebrew since Macports builds a ton of dependencies I don't want, while brew just downloads and installs a/some binary package/s. Fast and easy.
Actually this update specifically has finally started tracking dependencies vs directly installed packages, I don't know if they can GC old packages but atleast it now knows about them.
If you upgrade, and care about these things, don't forget to check your analytics settings:
brew analytics
I had my analytics options turned off prior to the upgrade, and after the upgrade - without any warning/hints/messages/notifications - analytics was back on again.
Underhanded applies malice here rather than a bug. If you can reproduce this behaviour: please file an issue and I'll fix it.
Also, as stated before (and the data dump hopefully shows): this is anonymous information that's useful for us and the community to be able to prioritise our limited resources.
Well, I can't reproduce it now because I've already upgraded, and as far as I can tell there is no way to go backwards.
Its underhanded in the sense that there is no message to the user that this is occurring. I do understand your need for this feedback, but I do not think that home-brew should change this setting once the user has set it to "do not report". This is key to the adoption of homebrew in some environments - for example, on some corporate networks having automatic exfiltration of analytical data, anonymous or otherwise, is instant disqualification for installation - and I've already had that conversation with our sysadmins, who notice these things almost immediately.
If there is something I can do to help you debug this, let me know - otherwise I'll just happily continue upgrading home-brew as time goes by, and if I see something, I'll say something.
> but I do not think that home-brew should change this setting once the user has set it to "do not report"
We never intentionally do so and never have. Other than your comment we've not had any mention that this is the case. If you can find a way to reproduce this and file an issue, that'd be great and I'll do my best to fix it as soon as possible.
https://brew.sh/analytics/
Neovim is about as popular as emacs now (backhanded compliment?).
We just released Neovim 0.2 (now supports Windows) a few minutes ago, so it's funny to see Homebrew and LuaJit releases on HN now.