homebrew-graph VS homebrew-cask-versions

wat.

Of course the recursive update policy is going to be weirdly painful for some users! Homebrew doesn't even attempt to encode some very basic aspects of dependency. The choice you outline above is one that is not faced by most package managers, because they don't make this mistake. The naive wheel reinvention with Homebrew is so eternally disappointing, and it inevitably explains a lot of the pain users experience with it.

> Homebrew upgrades dependencies and dependents of those dependencies (which, admittedly, can feel like unrelated)

One relatively non-disruptive thing you might be able to do to make this behavior less surprising to users is (offer a way to?) print the dependency tree for package installations/upgrades that pull in upgrades of their ‘siblings’. You'd probably want to just do it in a textual way, but this project seems to model the kind of logic you'd want for printing dependency trees with Homebrew as it exists.[2]

—

1: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

2: https://github.com/martido/homebrew-graph/blob/master/cmd/br...

https://github.com/Homebrew/homebrew-cask-versions/blob/master/Casks/safari-technology-preview.rb -> that would brew install safari-technology-preview then, remembered it right.

> If I just wanted to install google-chrome, sublime, and skype, I would use the app store.

None of those is available on the Mac App Store. I don’t understand the argument you’re trying to make.

> In contrast to how it used to be, Homebrew now seems designed for people that only want popular bleeding edge packages, and nobody else.

Homebrew Cask—which is what you’re referring to in the reminder of that paragraph—has always been focused on the latest versions of packages. The versions repo[1] is secondary with stricter rules for acceptance.

[1]: https://github.com/Homebrew/homebrew-cask-versions