> WARNING: ALPHA SOFTWARE > Sapphire is experimental, under heavy development, and may be unstable. Use at your own risk!

Ruby seems fine for brew. Does this do anything else better? Ruby makes it easy to write recipes for it which is a huge boon for a package manager.

My thoughts exactly.

The main reason I find brew to be a bit slow is just a lack of parallelism with regards to downloads and installs. Rather brew does alternating and sequential D, I, D, I, D, I, when I wish it just kept downloading in the background when it is doing the installs. It would cut down the brew upgrade time by 30% or more at the cost of more disk space used during the process.

But this one qualm I have isn't a result of its language implementation at all.

Ninite (https://ninite.com) in comparison does keep downloading in the background while doing the installs sequentially. This is the way.

I think AI assisted software generation will lead to a proliferation of tools doing the same thing because the effort to create them is so low. But then we will likely be choosing which tool to use based on community site/support/momentum rather than just features.

Ruby isn't web scale. Rust is web scale.

Hey, so I built this thing, most of it at so far at least. And yeah, right now it isn't doing many things better than Homebrew.

Setting of relative paths for bottle installs is still not perfect, well it works for every bottle I have tested except rust. Getting bottles working 100% is very doable though imo.

Build from source formulae is still pretty f*ed + I do not know if it is really feasible given that the json API lacks information there and a full on Ruby -> Rust transpiler is way out of scope. Will probably settle for automatic build system detection based on archive structure there. + Maybe do my own version of the .rb scripts but in a more general machine readable format, not .rs lol

Casks seem to work but I have only tested some .dmg -> .app ones and .pkg installers so far though. As with bottles 100% doable.

Given that almost all formulae are available as bottles for modern ARM mac this could become a fully featured package manager. Actually didn't think so many people would look at it, started building it for myself because Homebrew just isn't cutting it for what I want.

Started working on a declarative package + system manager for mac because I feel ansible is overkill for one machine and not really made for that and nix-darwin worms itself into the system so deep. Wrapping Brew commands was abysmally slow though so I started working on this and by now I am deep enough in I won't stop xD

Anyway I am grateful for every bug report, Issue and well meaning pull request.

What makes you interested in a rust implementation of brew?

I'm guessing it's that you hoping that it is eventually more performant -- are there specific areas of current brew you have identified as performance bottlenecks likely to eventually benefit from a rust implementation?

Or any more info to share about assumptions/hopes that motivated this or any other motivations?

I was a macports user but had to switch to homebrew because most new projects went there and it was generally easier to write Formulars etc. But I never really liked the project. I think writing a new package manager on top of brew infrastructure won‘t create a better setup. I don‘t know if all casks and Formulars only use the DSL stanzas or if still some use custom ruby functions and helpers. Because otherwise this new tool might need to eval ruby scripts for backwards compatibility.

I wish homebrew was a little more friendly to installing in a directory other than what the installer sets. I used to have a lot of permissions issues back when /usr/local was the only directory and none since I started installing it in ~/.brew

It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences.

FWIW the author of Homebrew is also working on a next generation package manager in rust: https://pkgx.dev/ (beware facebook tracking and infinite AI slop)

Wow. They really don't want anyone to take this project seriously! This is actually making me reconsider having brew installed even...

https://github.com/pkgxdev/pantry/pull/5360#issuecomment-233...

Creator, not current maintainer. Homebrew is currently maintained by over a dozen people, myself included.

Oof. Those AI images really harm the credibility of the package manager.

I both like and dislike them. First thing I searched for was the prompts, but I haven't found them yet.

As for Facebook tracking I 100% dislike that.

What’s the deal with the cautious warnings? Is homebrew being replaced by software developed using a “vibing coding” or what have you?

if you see the issue I linked, there are a lot of thumbs up / thumbs down in the comments, it's not just me =)

I finally looked up the GitHub repo found some context about the website: https://github.com/pkgxdev/pantry/issues/5358

What is it doing better than homebrew ?

Given homebrew was strictly worse than the tool it displaced, I’m not sure it’s the right question to ask. MacOS package management is strictly marketing based.

That’s not fair. Homebrew has been fantastic. It’s also open source, did they not accept your pull requests for these “improvements”?

> It’s also open source, did they not accept your pull requests for these “improvements”?

I don’t think you are being fair. This question presupposes that the supposed problems can be solved by iterative changes, rather than being inherent in the chosen design/architecture of the software, which usually requires complete replacement thereof (as well as the leadership thereof, as people who choose poor solutions to problems often can’t appreciate arguments for superior solutions).

(Not that I’m trying to suggest that I agree that homebrew in particular is bad — just speaking generally.)

They spent months fuding MacPorts before putting in place exactly what MacPort was doing because it turns out it’s the right solution and despite that the ergonomic is still garbage (try installing packages outside of the default folder for a good laugh).

Who is "they"? I've never FUDed MacPorts, and in a decade of contributing to and maintaining Homebrew I can say honestly that I've never heard any other maintainer talk much about it beyond user experience.

(Beyond anything else, Homebrew's biggest "win" over MacPorts was and probably is still UX and DX. The core technology of a packaging ecosystem is rarely itself the differentiator.)

At the time I switched from macports to homebrew (years ago?), homebrew could install more things I needed without any errors. Many more.

That was it, that's why I switched, nothing more, nothing less.

Macports was less ergonomic imho, which caused the community to shift to homebrew.

This. There is plenty to dislike about Ruby, but it is exceptionally strong at implementing domain specific languages. Homebrew was able to use that to lower the barrier to packaging software.

Also, using Git + GitHub instead of SVN + Trac was absolutely a winning pick for scaling project participation back in the 2000s.

Not sure why the subtweet, but I'll guess it was macports, which in my experience was not as fun or easy as brew.

back in the day macports was a fucking nightmare. homebrew may not be perfect but it is popular for good reason.

I doesn't have to do anything better. It's in Rust and that should be the only reason you need to switch.

Right now probably not much, it's WIP.

Having different project leadership is probably a big selling point ;)

What exactly went down with homebrew? Suddenly my employer was pulling it from every device and I never really got a solid explanation of why! I've not been able to get anything meaningful from searching on my own, obviously. Someone help a guy out?

Homebrew itself is not bad, but it does allow users to install software from thirdparty sources, that are unvetted, or unverified. This could pose a security risk. I can see why some companies will disable homebrew. Especially for non-developers.

Homebrew doesn't suddenly add that capability. It just facilitates it. If nothing else, it's easier to track what's been installed via brew than whatever the user may have curlbashed or untargzed to their home.

I think they’re specifically asking about the project as opposed to the tool

Does homebrew have bad leadership?

Ok, but then what goals do you have with it? What are you trying to solve/improve upon?

I hope it is faster. Homebrew operations take forever for me.