Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
It seems this is the issue in question: https://github.com/Homebrew/brew/issues/9186
The maintainer did close they issue but they didn't lock the thread. If there was a very valid reason the request got shot down, it went unstated afaict. (Fair enough if they just don't allow feature requests on the issue tracker, I guess)
For PostgreSQL on macOS I use and suggest https://postgresapp.com/ which is free and able to manage multiple Postgres major versions. It's also self-contained in a folder in /Applications. Also, version 14 of Postgres in the app has m1 native support.
yeah, i definitely think your point stands
the only place i know of where you can (easily) report an issue with a specific package is https://github.com/joyent/pkgsrc/issues
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...
I also use Nix, and agree with these caveats. My personal experience is that it can be hard to initially set up Nix, but once you do, it's rock solid. It's particularly great for sharing config across machines. Here's my personal dev environment for instance: https://github.com/mjhoy/dotfiles/blob/main/nix/nixpkgs/conf...
Conan can be made to do what homebrew does with minimal effort, I have written some convenience wrappers around it which makes it slightly easier to use for this use case, you can have a look here: https://gitlab.com/aucampia/proj/xonan
Regarding GUI applications: you're probably talking about the Nixpkgs repository, rather than the Nix tool itself.
I use the following Nix function to install GUI applications https://github.com/cmacrae/.nixpkgs/blob/d4b51eb414b0edaffae...
It doesn't work for everything, but I use it at the moment for Amethyst, DBeaver, DockerDesktop, Emacs, Firefox, iTerm2, Postman, Slack and VNCViewer.
> Homebrew is old and it needs to be replaced. It has served its time.
You are more than welcome to build your own alternative. Homebrew is open source and volunteer run. I'm sure there is a very valid reason requests like this get shot down.
No wonder open source maintainers hate dealing with people like you.
`nix-env` is an imperative command, whilst writing a .nix file is declarative. In particular, the latter can be managed using git.
For example, here's a system-wide config dating back to Feb 2015: https://github.com/Warbo/nix-config
(That's actually a NixOS config; my macOS config is in a private repo, but it imports that repo to define its "one big system package")
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...
I built a feature in arkade [1] to pull in binaries for CLIs for infrastructure and developer tooling that I wanted to use - it now has 72 CLIs that you can pull down with a single command and most importantly, as near to instantly as you're going to get.
For instance: arkade get [email protected] yq helm faas-cli
It's not got anywhere near the catalog of brew, and doesn't compile software, or help you find lib-xyz for your Yubikey, but it is really fast and has a growing community behind it.
It works on MacOS, Linux, Windows and arm hosts to determine the correct download URL and pull in a binary.
[1] https://github.com/alexellis/arkade
Contributions are welcome.
> 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.
Fight through it for another couple of weekends - the Stockholm syndrome feels sooo gooooood!
I found it much more helpful to find people's own Nix setups and learn from them, by the way. Mine is at https://github.com/Smaug123/nix-dotfiles - like all such things, it's a WIP, and I'm definitely still a noob, but bits of it may be able to help.
