Homebrew 1.2.0
brew.sh
brew.sh
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.
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."
Our ice cream is great though.
https://github.com/emacs-mirror/emacs/blob/emacs-25.1/etc/NE...
(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.)
% EDITOR='grep url' brew cask edit emacs | tail
url "https://emacsformacosx.com/emacs-builds/Emacs-#{version}-universal.dmg"I'm curious about the EDITOR=... though rather than: brew cask cat emacs|grep url
Anyone have any suggestions for things to look at first?
You had me at directory structure. Then you lost me at "bottle", had me at tarball again, but by then I was exhausted and don't care any more.
Terminology is important because it has application for the end user. I don't get any use out of tap/keg/cask.
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.
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. -.-
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?
Can we move on as a community and drop this?
But we're also allowed to criticize your criticism too.
The other isn't even close: "Instead of criticizing this free software, write your own".
brew install thing-i-want
The metaphors could be a little bit clearer.
Naming things has always been hard.
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?
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.
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.
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.
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.
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.
Your milage will of course vary, and I suspect that more popular packages are probably updated much more aggressively.
[1]: https://www.macports.org/ports.php?by=name&substr=pandoc
[2]: http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014
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.
https://hn.algolia.com/?query=homebrew&sort=byPopularity&pre...
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.
brew analytics
A bit underhanded, but I'm used to it by now.
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.
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.
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.
However in 2017, if you're interested in a desktop OS with a bunch of Unix tools available, apt-get on Windows works perfectly.