
Homebrew 1.0.0 - robin_reala
http://brew.sh/2016/09/02/homebrew-1.0.0/
======
tbrock
I've worked with mike to maintain formula for years and he is always pleasant
and on top of things in what is a very hectic job.

Homebrew is such a good package manager (and not for the reasons any package
manager is classically considered good). It's great because the community is
so vibrant, the user experience is so well thought out, and the formula dsl
makes so much logical sense. It's actually both a GitHub and Ruby showcase.

Thanks homebrew team! Here to many more years of accessible packages on the
Mac.

~~~
stephenr
> not for the reasons any package manager is classically considered good

You can say that again. Homebrew's dependency management is a fucking joke, to
the point that it might as well not exist.

~~~
freehunter
That's the reason I stopped using Homebrew and plenty of other comments have
said the same thing. Maybe it's changed recently, but last time I used it
(about a year ago), dependencies were not cleanly resolved in every case.

~~~
sperglord
What better alternative exists?

~~~
stephenr
Depends what sort of packages you want.

I used to use it for things like local installs of server-side stuff (e.g.
language runtime, database server, cache server, etc) but I've moved to using
vagrant (and in turn Debian, so Apt) for those things.

For dev tools such as Mercurial, Git, Autotools, etc there are first/third
party .pkg installers available.

------
rogual
As a user, Homebrew is a great experience.

As a package maintainer, though, one thing surprised me: you can't make your
package depend on a specific version -- even a major version -- of a library.

So if MyApp uses YourLib 1.0, everything is fine until YourLib 2.0 comes out,
at which point users doing `brew install myapp` will start getting cryptic
compiler errors. I have no choice but to drop whatever I'm doing and make
MyApp compatible with YourLib 2.0, which may even be impossible.

It's just odd because otherwise Homebrew is so well designed. It seems like a
weird omission.

Edit: Some packages get around this by packaging major versions separately
(qt, qt5) but most don't.

~~~
oefrha
"everything is fine until YourLib 2.0 comes out, at which point users doing
`brew install myapp` will start getting cryptic compiler errors."

Sorry, this is just not true, we hold merging YourLib 2.0 into core until all
dependents are upgraded or boneyarded. Maybe you're speaking from your
outdated experience with brew years ago.

Also, we do have plans to support multiple versions of libraries, see
[https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620)
"Handle Versions Better" (although I'm not necessarily a fan of this
personally). We also have an openssl@1.1 formula in core already in case you
want a sneak peek of the future.

~~~
oefrha
To be clear: I'm only talking about core here. If you try to compile external
software against brewed libraries, of course you may run into problems, but we
do have the homebrew/versions tap, and you can always host your own taps for
outdated libraries.

~~~
rogual
Thanks for responding. Yeah, my package isn't in core, although it seems I
would just have a different problem if it were (upgrade to YourLib 2.0 or get
boneyarded)

I get that it's all a tradeoff, and it must to help keep complexity down if
brew is latest-everything.

New versions stuff looks good. I'll look into the versions tap too.

~~~
oefrha
> I would just have a different problem if it were (upgrade to YourLib 2.0 or
> get boneyarded)

In core this is true. In your own tap you can vendor your dependencies however
you want.

------
Empact
Throwback to that one time Google wouldn't hire @mxcl. ;)
[https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

Well done Mike and contributors! It's a great piece of work.

~~~
itchynosedev
It's hard for me to understand the issue with this. Google didn't hire the guy
who wrote software that had a big impact on the community. Does it mean Google
misses good engineers because of their less-than-ideal interview process, or
simply Google hires only people who are a good fit for their organisation?

Writing the overly bitter tweet surely won't help with improving hiring
points. Seems highly unprofessional and childish.

~~~
asendra
Well, he's at Apple now in charge of the Swift Package Manager, so I think he
did okay.

~~~
hboon
He left.

~~~
allsystemsgo
Yeah I'm curious why he left. From what I could tell it sounded like changes
in Swift took an act of congress basically. Which is fine, and how it should
be, given how important it is to get it right. I wonder where he went.

~~~
eridius
My understanding is he just doesn't really know how to work in a big company.

~~~
aphextron
Meh. I know "how to work in a big company" and choose not to. Talented people
will always do whatever they want.

~~~
eridius
You choose not to, but you could if you wanted to, right? He apparently wanted
to, otherwise he wouldn't have gone to Apple in the first place, but he just
doesn't know how to work in a corporate environment. In fact, he says as much
in this tweet:
[https://twitter.com/mxcl/status/773574683518119936](https://twitter.com/mxcl/status/773574683518119936)

~~~
veidr
You seem to be looking at this through a somewhat unusual prism.

You and I both "know how" to eat discarded food out of a trash dumpster.

But absent some truly compelling reason, we wouldn't _choose_ to do so, right?

------
matt4077
Among all the software I use, Homebrew must be the one giving me the least
trouble. I have 100 installed packages and I don't remember the last time
anything didn't work. Plus, for anything I care about, updates seem to always
take less than a day, usually it's almost instantaneous.

In comparison with MacPorts before, it's like night and day.
npm/pip/mix/bundler all seem to periodically conspire to waste a few hours of
my time (even though I can do that quite well on my own).

NPM being the worst of the bunch. By a lot. About this much:

`tree node_modules`

~~~
philplckthun
So npm is bad in your opinion, because it correctly handles different
dependencies on packages with varying versions, screwing up? Or is the problem
the vast js ecosystem?

I don't think that "tree X" can be a good argument against using any kind of
package manager.

~~~
kminehart
It's just popular to hate JavaScript and npm right now.

It's not perfect, but it's not bad either.

~~~
philplckthun
This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes
for the PHP counterpart. I think it's fine to search for better solutions for
our backends, but there is no denying that 1) our browsers rely on JS and will
do so for the close future, and 2) that there is an ecosystem for every
programming language that can use it efficiently and proficiently.

------
princetman
"brew update

Error: /usr/local is not writable. You should change the ownership and
permissions of /usr/local back to your user account: sudo chown -R $(whoami)
/usr/local

.

.

.

==> Migrating HOMEBREW_REPOSITORY (please wait)...

==> Migrated HOMEBREW_REPOSITORY to /usr/local/Homebrew!

Homebrew no longer needs to have ownership of /usr/local. If you wish you can
return /usr/local to its default ownership with: sudo chown root:wheel
/usr/local"

You got to love the user experience of this! Thanks Homebrew team. <3

~~~
oefrha
I see no problem in this. We need writing permissions to /usr/local to finish
our migration (as we always did). Once you finish the migration we (hopefully)
never write directly to /usr/local again.

~~~
oefrha
Sorry, I probably failed to notice the "Thanks Homebrew team. <3" part first
time round.

------
adidalal
Just wanted to highlight that as of this release, all the core code for
Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into
the Brew codebase. This should allow for tighter integration between the two
and a renewed focus on making installing GUI apps as painless as possible!

From a user/developer perspective, we've created a command line utility
(`cask-repair`) to make version bumps as painless as possible. Would love to
see more people using it [0], and we welcome suggestions and PRs (we have a
few long-standing issues that have gone unaddressed, and fresh eyes are always
good!)

[0] [https://github.com/caskroom/homebrew-
cask/blob/master/CONTRI...](https://github.com/caskroom/homebrew-
cask/blob/master/CONTRIBUTING.md)

~~~
dcosson
Looking forward to checking this out. One issue I have run into with homebrew
is that due to varying packaging choices as a project grows, I've seen stuff
move back and forth from brew core to cask to neither, and the old ones stick
around at the outdated version so you have to be careful when you tell people
to install the thing (seen this happen with terraform for example, which a
month ago when I last checked existed as a year-old version in a cask, a few
months old version in core, and the current version wasn't available in
either).

It might be cool to also allow some kind of process for marking packages as
deprecated and showing a warning or confirmation prompt if you try to install
it, for the cases when maintainers start packaging in some different way that
can't be supported by homebrew.

~~~
adidalal
We do have a `deprecated` caveat, but we rely on users to bring up that fact,
as there's no way the maintainers can keep track of the status of every Cask.

There's also a fairly large push and discussion about removing duplication
between Homebrew core and Homebrew Cask, so you should see things improve.
There should also be Formula -> renamed Cask migration at some point, the
issue has been raised in brew-evolution. (We have basic Cask <-> Formula
support already).

Re: terraform specifically, looks like it's now in core, and `brew cask
terraform` will know to do `brew install terraform` automatically.

------
mirekrusin
Be aware of "update bug"

If Homebrew was updated on Aug 10-11th 2016 and brew update always says
"Already up-to-date". you need to run:

``` cd "$(brew --repo)" && git fetch && git reset --hard origin/master && brew
update ```

I had to.

~~~
Bhullnatik
It took me way too long of daily `brew update`s to notice something was wrong.

~~~
tracker1
it's funny, but other than a few basic tools, most of what I get from homebrew
is versionables (nvm, pyenv, etc) of other programming utilities, in that, I
don't run brew update very often, usually only before installing something new
via homebrew.

------
FabHK
Brew is awesome. Note though that it gathers anonymous aggregate user
behaviour analytics and reports to Google Analytics, see [https://git.io/brew-
analytics](https://git.io/brew-analytics) .

You can opt out with

    
    
        brew analytics off

~~~
mikemcquaid
That's obviously fine for you to do but it's worth noting that we remove
software that no-one uses where "no-one" is defined by "no-one using
analytics". That's actually our main use-case for analytics.

~~~
falcolas
> we remove software

Why? Personally, the only reason I would remove software from a repository is
if it didn't work, impacted performance, or cost me an unreasonable amount of
money/time. There's a really long tail for software packages.

~~~
mikemcquaid
In short: we generally only remove things when they break, break other things
or the projects are dead. How hard we try to fix these things generally come
down to how used our analytics say they are.

~~~
a-no-n
How did the "royal we" arrive at this "reasoning?"

If popularity were a valid signal of importance, people should only express
their eternal love for PHP and Javascript, and ignore computer science,
functional programming languages, computer engineering and little-known-but-
really-fucking-important packages.

Call me ageist, but code churn and labeling projects "dead" adds nothing in
the context of portable code which has matured to the point stability; there's
zero functional value added in refactored code being "new." Ongoing support,
adding features and keeping pace with platform compatibility are separate
issues from judging code to be "inferior" despite working because it's "old."
What may seem "dead" to people whom don't know about particular packages but
may well just be stable and resting very quietly because it just works.

~~~
mikemcquaid
If projects are portable and continue to work without patching indefinitely:
we don't consider them dead. What we're unwilling to do is to apply patch
after patch to unmaintained and undeveloped projects to keep them working on
macOS; at that point we're forking the project and lack either the desire nor
people power to do so.

------
VeejayRampay
Homebrew is a huge help that perfectly fills the niche it's intended for.
Thanks for all people involved, you're time savers, which is pretty much the
most sought after quality of a software project.

~~~
pikachu_is_cool
Except for loading the Ruby VM. Takes way too long.

~~~
mikemcquaid
Which is why for certain things like `brew --prefix` we now do it purely in
Bash rather than using Ruby ;)

~~~
barpet
Why would bash be faster ? Would not you essentially call the same C lib stuff
anyway ?

~~~
s_kilk
It would at least save the process-start overhead, plus loading the ruby vm
and modules/gems.

~~~
mikemcquaid
Exactly. For a simple string comparison Bash is far faster (although Homebrew
doesn't use require any gems, just FYI).

~~~
s_kilk
Good to know, so did the speedup come mostly from not spinning-up the Ruby VM?

~~~
mikemcquaid
Yep!

------
gmisra
If Mike is still here in the comments, can you talk a little bit about
versioning support? Is this something that's on the roadmap at all, or
something that Homebrew has a strong opinion about?

In general, it's a very useful (and pleasant to use!) tool - except for when
trying to manage different versions of the same dependency on the same system.
Since this is such a big deviation from most package managers, and feels
intentional, I'd like to understand why, and whether there is a "homebrew way"
of approaching multi-version management.

Thanks again for all of your hard work!

~~~
mikemcquaid
We're working on it:
[https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620)

------
Keyframe
I have a stupid question. Is there a dogmatic way of listing installed things
and sharing that with other brew?

For example, I now list with brew list into a file and edit the file so that
whole list is a big brew install. That way if I reinstall OS or go to another
I can have same things.

~~~
StyloBill
Not sure if that's what you wanna do but you could do :

"ls /usr/local/Cellar/ | cat >> myInstall.txt"

~~~
Keyframe
I just do this for now:

 _cat <(echo brew install) <(brew list) | sed ':a;N;$!ba;s/\n/ /g' >
brew_install.txt_

It lists directly from brew, prepends brew install and then replaces all
newlines with a space and outputs to brew_install.txt

~~~
jfb
I use brew leaves instead of brew list for this sort of thing; as I usually
don't care about the constituent transitive dependencies, only the final
results.

~~~
Keyframe
I wasn't even aware of existence of that!

~~~
jfb
Yeah, I don't know if it's mentioned in the docs. I had written my own version
before I found it.

------
_kyran
Thanks to Mike and everyone else that has contributed to Homebrew. I couldn't
imagine how difficult it would be managing command line programs on a Mac
without it.

~~~
tangue
I'm wondering if Macs would be as successful with developers without homebrew.

~~~
panglott
Mac OS X came out in 2001, and there was a lot of immediate adoption by people
using emacs and bash: It became the largest consumer distro of a Unix-based
system overnight. (look for all the old articles about how to upgrade from
tcsh to bash).

Homebrew was successful because there were developers who wanted it. Is the
Mac more successful as a developer platform because of it? Possibly.

~~~
tangue
It's fun to read all of this. I re-read John Siracusa reviews and some old
blogs and yes, until Snow Leopard OSX was THE cool hackers' OS. And when Apple
didn't invest in power users anymore, individuals took over.

------
jason_slack
Thank you Homebrew!

As corny as this may sound. I rely on Homebrew to get my unix experience on OS
X and not have to compile everything myself. Saves me time and is one less
wrench in my development process.

------
faitswulff
As a developer, I'm intimidated - Homebrew sets an extremely high standard for
software 1.0 release quality.

~~~
tedmiston
Remember how long Gmail was "beta"?

~~~
tracker1
The funny thing is how quirky the gmail settings look compared to the rest of
gmail these days... it works, but it just doesn't quite fit. Though on the
flip side, I don't like how much they changed contacts, and that I can't
initiate SMS messages from contacts web ui anymore.

------
saynsedit
/usr/local was bad but /usr/local/Homebrew is worse.

The best would have been /opt/brew (short, no uppercase letter)

~~~
tnorthcutt
Why is /usr/local/Homebrew bad?

~~~
saynsedit
Because the UNIX hierarchy is standardized. System admins only expect bin,
lib, etc, share, etc. to be in /usr/local. Imagine deleting /usr/local with
the intention of only deleting local packages and accidentally breaking a
Homebrew install.

Not to mention it's an uppercase H which breaks UNIX file name convention.

------
laurent123456
Homebrew is quite an achievement, it grew in complexity over the years, yet
remained reliable and kept a user-friendly interface.

It's also very simple to create packages, it took me less 30 min to learn how
to create a package and to deploy it. In comparison last time I checked,
creating deb packages is absurdly complex, and I usually just give up and
provide a Bash file instead.

~~~
_RPM
I find your statement laughable. Brew and Debian's package manager aren't even
comparable.

~~~
laurent123456
apt-get has a wider scope but, in some cases, what it is needed for is to
deploy a simple application, and there's no simple way to do that with Debian
packages.

------
DerDangDerDang
I like brew, but it's complete ignorance of OSX deployment target version
(macosx-version-min) means it's useless for building software intended to run
on machines other than the developer's. Most commercial software in other
words.

I realise that's outside of it's intended feature set, and it's fine for
getting dependencies for other people's github projects or whatever. But what
I'd really like is the ability to get dependencies that I can feed into my CI
system to build software I intend to give to end users.

------
sergiotapia
Thank you guys for making my life as a software dev and end user infinitely
easier.

\- brew install postgresql

\- brew install mpv

The list goes on and on and on. You rock!

~~~
danielsamuels
Postgres.app[1] would make your life even easier. :)

[1]: [http://postgresapp.com/](http://postgresapp.com/)

~~~
sergiotapia
I switched to use the homebrew version because I couldn't get the pg tools and
such to work from the command line. Nobody got time for that. :P

~~~
tibbon
After doing both homebrew and Postgresapp for a while, I've switched to using
Docker to run it. It's really nice because then on a per-app basis I can have
separate versions easily and all checked into version control.

------
sigjuice
From the announcement: _Use new Ruby Macho library for reading and writing
library macOS Mach O file locations._

Why does Homebrew need to parse Mach-O files? Is this for fixing up shared
library paths inside executables?

~~~
woodruffw
Author of ruby-macho (the library being used) here:

Yes, exactly. During bottle installations, we need to be able to relocate
dylib references and install names so that they're relative to the Homebrew
prefix.

------
mrweasel
I've had few (minor) issues with Homebrew, so I've been wondering about
pkgsrc. Has anyone tried using pkgsrc, as a replacement for Homebrew?

~~~
eddieh
I found pkgsrc to to be pretty great, but some of the packages are organized
in odd ways and badly named. For example TexLive isn't called texlive. Same
with xorg-server. I also couldn't figure out how to install Mac specific
variants of things like Emacs. So I'm not giving up MacPorts anytime soon.

------
dudul
Homebrew is really great, and I recently discovered cask (I know, lame, but
I'm a MacOS noob :) ) and it's so nice. No more downloading freaking dmg,
mounting, dragging, clicking a bunch of popups, no more visiting the app
store.

How is this thing not integrated in MacOS yet?

~~~
adrianN
> no more visiting the app store

You answered your own question.

~~~
dudul
True for Cask, but unless I'm mistaken, cask is a plugin for Homebrew. It is
not part of the vanilla install.

~~~
rrdharan
That has changed - it's now part of the main project.

~~~
dudul
Interesting, my bad then :)

------
thomnific
Ugh, ugh, ugh. I just tried Homebrew for the third time the other day and it
made a complete mess of my /usr/local/bin and also screwed up my install of
rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is
crufty, opinionated software with poor separation of concerns. Macports is the
(objectively?) better choice for my needs.

~~~
Osmium
> it made a complete mess of my /usr/local/bin

In that case you might be glad to hear that in v1.0.0:

> Homebrew’s default repository installation location changed to
> /usr/local/Homebrew to keep your /usr/local cleaner

Personally, I really like Homebrew and have never had problems (c.f. MacPorts
which gave me big problems a few years ago), but I don't use /usr/local for
much else, so that's probably why.

~~~
thomnific
Heh, fair enough and thank you, good to know :) Maybe in another year or two
my frustration will have abated somewhat. Don't get me wrong, I think it's
great that the devs recognized using /usr/local/bin was a bad decision (even
if they were kind of forced to because of Apple's SIP).

However -- I just remember, when Homebrew was getting started, all the
supercilious (dare I say arrogant?) advice in the docs ... oh, just install to
/usr/local, "seriously", etc. (Looking for a reference in archive.org right
now ...) Even their whole "Macports driving you to drink?" thing rubbed me the
wrong way -- maybe I'm humour-deficient, but I think to criticize another
project when your alternative isn't clearly better is just bad taste.

That being said, I am genuinely curious: is there any one awesome thing is
that Homebrew does that Macports can't do? Or better, what kind of problems
arise from using Macports? I recognize that packaging in Ruby is probably more
convenient than in TCL, but other than that? It seems to me that Homebrew is
just getting closer to what Macports did (correctly) in the first place. The
only way Macports has ever inconvenienced me is requiring a fresh install from
time to time when Apple updates their OS, which (for my use case) is minor.

------
niahmiah
Homebrew used to be my go-to tool for installing packages...

But now, with the new Docker for macOS, I never need home-brew anymore. It is
especially helpful when you need to run 2 different versions of an app (like
elastic search) for different projects.

I can't see myself returning to Homebrew now. That is just not the way to do
things anymore.

~~~
kstrauser
Apples and oranges. I brew install git, Emacs, jq, and other dev tools.
Packaging stuff in Docker is fine, but first you have to create or fetch
something to package.

------
crooked-v
As a side note, Ansible users might be interested in the roles I've been
putting together for a bunch of the apps I regularly use [1].

You can kinda use homebrew-bundle in place of some of this stuff, but even
then there's random installs that need extra configuration or general mucking
about with that homebrew-bundle doesn't give a good way to encapsulate (for
example, see the duckdns-updater repo and the template it uses [2]).

[1]: [http://galaxy.ansible.com/icopp/](http://galaxy.ansible.com/icopp/) [2]:
[https://github.com/icopp/ansible-duckdns-
updater](https://github.com/icopp/ansible-duckdns-updater)

------
emdowling
There has been a lot of talk in HN comments recently about Homebrew installing
to `/usr/local`. With macOS Sierra, the user can no longer write to this
folder without specifically owning it. Is there a security risk here and if
so, whats the best workaround?

~~~
elmigranto
Newer versions install in `/usr/local/Homebrew`, older versions "migrate"
there:

[http://apple.stackexchange.com/questions/253404/how-does-
hom...](http://apple.stackexchange.com/questions/253404/how-does-homebrew-no-
longer-need-ownership-of-usr-local)

~~~
netheril96
I have a hard time understanding the "migration", even after reading all the
related issues. Homebrew still writes into /usr/local/bin and
/usr/local/Cellar, nothing different from the past. What exactly changes?

~~~
oefrha
Writing to /usr/local/bin is not the same as writing to /usr/local. We don't
drop a README.md in /usr/local anymore, for instance, and you can change the
ownership of /usr/local back to root:wheel after the migration.

------
rvalue
I enjoyed working and using Homebrew. My first contribution was to bring
python 3.5.1 to brew. Loved the processes they have in place for anyone to
make a change and have it available for distribution for the whole world using
brew on OSX.

Great job for the brew maintainers and contributers. You guys make everyone's
job a lot easy!

------
kersten
brew update

brew --version

~~~
icantdrive55
Kersten is a nice name.

~~~
kersten
Thanks. icantdrive55 is equally romantic ;)

------
Flimm
I'm excited about Homebrew potentially coming to Linux. When I first started
using OS X more regularly, I was surprised by how better an experience OS X +
Homebrew is compared to Ubuntu/Debian repositories + PPAs/third-party
repositories.

~~~
paublyrne
I don't use Linux myself, but am curious as to why this has been so heavily
downvoted.

~~~
cupantae
I personally don't use Mac OS(X), but what I understand is that Homebrew is a
project designed to give the functionality of a Linux command-line package
manager to OSX.

For most (all? Slackware...) Linux distributions, there is ONE package
manager: for Debian/Ubuntu it's APT, for Arch it's Pacman, for RedHat &
friends it's RPM, etc. There is exactly one, because all the files which
aren't user data or configuration are owned by some package or other. It's all
well and good when there's a clear need for this on OSX, and so Homebrew must
keep up to date with the official software management and keep itself
contained, not breaking anything. Having a second package manager on Linux,
which doesn't treat Linux as the main target platform, seems both pointless
and asking for trouble.

Alternatively, you could be harsh and figure that the downvoters were saying,
"No, you don't prefer Homebrew. You prefer your distribution's package
manager, and thou shalt use it correctly."

~~~
amorphid
My issue with those APT on Debian is that I almost always have to add another
PPA to download a version of something that I actually want to use. That
reduces the utility of APT in my view. Having a crowdsourced list of Homebrew
packages to install would be fabulous.

~~~
tracker1
Not only that, but a lot of those PPAs become stale, or get replaced by
others, and it's only when you upgrade the dist, that you get failures and
discover this... It's pretty annoying. It would be nice to have a meta package
manager for "current" PPAs for given projects that wraps apt with brew-like
ability.

~~~
DeadBabyOrgasm
Additionally, creating and maintaining a PPA involves one of the following:

(a) Use the upload form for Launchpad.net [0]

(b) Host your own deb server [1]

Unless you use Bazaar for a VCS, the only time you login to Launchpad is to
upload a new release. With Homebrew it's built into git with adding a new tag.
A _LOT_ lower barrier to entry here.

[0]:
[https://help.launchpad.net/Projects/FileDownloads#Publishing...](https://help.launchpad.net/Projects/FileDownloads#Publishing_files)

[1]: [https://www.unixmen.com/setup-local-apt-repository-using-
ins...](https://www.unixmen.com/setup-local-apt-repository-using-installation-
media-in-debian-8/)

------
emmelaich
I can see a point in the future where everything is installed via a homebrew-
like process.

Forget CPAN, CRAN, ports, pypi, go-get, rpm, apt, cabal, crate, opam, ...

Just get it from github or similar with homebrew.

~~~
s_kilk
Doubtful, homebrew doesn't do any kind of dependency management, so it would
be a strict downgrade from pip, gem, cabal, etc

Edit: See comment from rogual elsewhere in this thread -
[https://news.ycombinator.com/item?id=12547076](https://news.ycombinator.com/item?id=12547076)

~~~
mikemcquaid
That's an exaggeration. We definitely do dependency management, we just don't
allow formulae in core to pin against arbitrary versions of software because
it often means security updates are never tracked. We are going to loosen this
slightly but not dramatically:
[https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620)

~~~
s_kilk
Thanks for the clarification. However, if Foo depends on Bar, will homebrew
track the dependency so that I can't upgrade Bar to a version incompatible
with the existing installation of Foo? I recall running into that issue a
while back, and it gave the impression of version tracking being an install-
time-only deal.

~~~
mikemcquaid
In homebrew/core and within taps we ensure those cases are handled by
`revision`s and CI checks. Across taps this is harder and we're working on it.

------
zpallin
Yesterday I was downloading a cask and homebrew told me to update because
homebrew no longer needs to own /usr/local.

I think that was a perfect way to be introduced to this release :)

------
FatherShawn
Homebrew has been my "go to" package manager for years! Well done!!

------
isarat
Should I go for a clean install, considering the structural changes?

------
isarat
Should I go for a fresh install, considering structural changes?

------
hmans
Good.

~~~
petrikapu
Has opt-out Google Analytics had any help for your project so far?

[https://news.ycombinator.com/item?id=11566720](https://news.ycombinator.com/item?id=11566720)

------
Pastina
I had uninstalled homebrew this week because it stopped functioning. Out of
nowhere, I started getting a ruby error related to a particular package and
every CLI call would fail because of it. As someone who works with Go, it's
sad to see an error bubbling up and not being gracefully handled.

~~~
amorphid
I had errors with Homebrew and Go this week. In both cases, it was an issue
with Websense (also known as Forcepoint). Might your issue be related to that?

~~~
Pastina
Brew claimed it couldn't find the downcase for another package, not Go.

~~~
oefrha
There were bugs in the past few days, but all known ones have been squashed as
far as I know, so all you need to do now is

    
    
      brew update
    

_at least twice_.

