As a long-time Python user, Homebrew jumping versions from 2.7.0 to 3.0 is a little disorienting. :}
Homebrew 3.0
91–100 of 516 posts
Re: Homebrew 3.0
#92Earlier quoted context omitted.
Can you explain exactly what you are describing: “it doesnt deal well with multiple versions at the same time” Also what system/os are you comparing to?
I'm comparing to macports. I remember a brew update that removed an old version of openssl causing all of my older ruby packages to fail. Now I would definitely not use ruby 1.9.x in production but I sometimes do have to be able to run locally antique codebases that haven't been used in a long time. I was caught off guard because a simple install of an unrelated application with homebrew destroyed a big part of my wo…
Why not just use rbenv with a $HOME/.gem directory. Much simpler as Ruby versions come with their own openssl.
Re: Homebrew 3.0
#93/me searches changelog for "`brew update` now runs asynchronously and doesn't block the process to install a 3 year-old package." Dismayed, I do not find it. Asynchronous formula updates would IMO save the most Mac man-years of almost any macOS tool.
I feel like it would be a /tremendous/ amount of work to install packages -- which often have dependencies -- asynchronously. When is this really a problem, anyway? You should probably not have something like 'brew update' scheduled to run periodically, as then a broken package could break something unexpectedly. It should really only be run when you're ready to check for broken things, which means you can also sched…
That’s what I did - I have `@daily brew update` in my crontab.
Re: Homebrew 3.0
#94I can’t even begin to imagine how much value Max Howell (creator of Homebrew) has added to the world. It’s the recommended package manager at every place I’ve worked at and saves so much headache. I use Linux at home and package managers like AUR are great, but macOS is where the users are.
Without this, the developer experience on Apple would be way worse, if not just plain shit.
Re: Homebrew 3.0
#95I can’t even begin to imagine how much value Max Howell (creator of Homebrew) has added to the world. It’s the recommended package manager at every place I’ve worked at and saves so much headache. I use Linux at home and package managers like AUR are great, but macOS is where the users are.
Wouldn't we all just be using MacPorts/Fink, like we were before Homebrew?
Re: Homebrew 3.0
#96Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
No. MacPorts is so much better nowadays.
In what way?
Re: Homebrew 3.0
#97/me searches changelog for "`brew update` now runs asynchronously and doesn't block the process to install a 3 year-old package." Dismayed, I do not find it. Asynchronous formula updates would IMO save the most Mac man-years of almost any macOS tool.
Why is this important
Re: Homebrew 3.0
#98Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
I find that MacPorts is a better citizen of my laptop, but the mindshare of homebrew means that brew will have both more packages and more up to date packages. And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.
I think that's the key, MacPorts stays in its lane. I also like the variant mechanism. It makes it easy (much like OpenBSD flavors) to get what I want out of it.
Re: Homebrew 3.0
#99Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful. In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
> found it a bit cumbersome with the “no sudo” requirement
This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
Re: Homebrew 3.0
#100Earlier quoted context omitted.
Fwiw you can use the Nix package manager ( https://nixos.org/ ) on OS X to accomplish those same things. Lots of discussion about that the past few years: https://google.com/?q=nix+on+mac+os+x Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there. And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew…
How is that better than a pm specifically designed for Mac?
I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful.
Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run.
If you've ever updated readline via Homebrew, you can pretty much just watch everything burn.
If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS.
If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.