[HN Gopher] Sapphire: Rust based package manager for macOS (Home...
___________________________________________________________________
Sapphire: Rust based package manager for macOS (Homebrew
replacement)
Author : adamnemecek
Score : 197 points
Date : 2025-04-22 18:39 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nartho wrote:
| What is it doing better than homebrew ?
| adamnemecek wrote:
| Right now probably not much, it's WIP.
| carterschonwald wrote:
| Having different project leadership is probably a big selling
| point ;)
| adamnemecek wrote:
| Does homebrew have bad leadership?
| Henchman21 wrote:
| 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?
| israrkhan wrote:
| 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.
| no_wizard wrote:
| I think they're specifically asking about the project as
| opposed to the tool
| cassianoleal wrote:
| 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.
| mort96 wrote:
| So does sourceforge and GitHub and similar, are those
| blocked too?
| gkfasdfasdf wrote:
| I hope it is faster. Homebrew operations take forever for me.
| carstenhag wrote:
| Ok, but then what goals do you have with it? What are you
| trying to solve/improve upon?
| StopDisinfo910 wrote:
| 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.
| user82747493 wrote:
| That's not fair. Homebrew has been fantastic. It's also open
| source, did they not accept your pull requests for these
| "improvements"?
| StopDisinfo910 wrote:
| 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).
| woodruffw wrote:
| 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.)
| StopDisinfo910 wrote:
| Just go read the original announcements of homebrew. They
| expend at length about how Macport was wrong for shipping
| its own tool chain and homebrew was somehow superior for
| reusing the one shipped with MacOS (guess how it turned
| out). The fact that most packages completely broke if
| installed outside of /usr/local (itself a non sensical
| default) was just cherry on the cake. And let's not talk
| about how everything broke if you didn't update often
| enough so much so that there somehow is a command to try
| to bring things back to sanity.
|
| Homebrew is by far the worst package manager I have ever
| used. I'm still sour it somehow dragged away packagers
| from solutions which were better in every way by being
| promoted as the "default" solution.
| woodruffw wrote:
| > Just go read the original announcements of homebrew.
|
| I can't find these anywhere on the official blog, which
| goes back to the first 1.0 release of Homebrew. Links
| would be helpful.
| Lammy wrote:
| Found it because I was curious:
| https://github.com/Homebrew/legacy-
| homebrew/commit/29d85578e...
|
| Here are the comparisons to other package managers:
|
| > Packages are brewed in individual, versioned kegs. Then
| symlinks are created to give a normal POSIX tree. This
| way the filesystem is the package database. Everything
| else is now easy. We are made of win.
|
| vs MacPorts registry which used its own homebrewed (lol)
| Receipts files in 2009, and now uses a SQLite DB: https:/
| /guide.macports.org/chunked/internals.registry.html#i...
|
| > I wouldn't worry about it not being root. We don't
| install anything base enough for it to be a concern
| (unlike MacPorts or Fink).
|
| vs MacPorts installs to `/opt/local` as root.
|
| > Why Not MacPorts?
|
| > =================
|
| > 1. MacPorts installs its own libz, its own openssl,
| etc. It is an autarky.
|
| > This makes no sense to me. OS X comes with all that
| shit.
|
| > 2. MacPorts support Tiger, and PPC. We don't, so things
| are better optimised.
|
| There is no "Why Not Fink?" section.
|
| And because I didn't know the word autarky:
| https://en.wiktionary.org/wiki/autarky
| woodruffw wrote:
| From 2009, so before my involvement. I'll note that this
| also says a bunch of things that aren't true in current-
| day Homebrew (Casks, for example, are distributions of
| .app bundles), so I think it'd be accurate to say that it
| doesn't reflect the project's current (or even past-
| decade) views.
| cstrahan wrote:
| > 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.)
| user82747493 wrote:
| Then fork it! Make a new or better one! Handwaving it's
| not good does nothing for anyone
| lxe wrote:
| Macports was less ergonomic imho, which caused the community
| to shift to homebrew.
| cls59 wrote:
| 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.
| Lammy wrote:
| Everybody forgot about Fink
|
| https://www.finkproject.org/doc/users-guide/index.php
|
| https://pdb.finkproject.org/pdb/index.php?phpLang=en
|
| (Not a recommendation; seems pretty dead)
| whalesalad wrote:
| back in the day macports was a fucking nightmare. homebrew
| may not be perfect but it is popular for good reason.
| jrochkind1 wrote:
| 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.
| cosmic_cheese wrote:
| This is why I switched as well. At that point the brew
| experience was a lot closer to that of apt on a Debian-
| based Linux distribution or something where you could
| reliably run "x install <pkgname>", get up to go grab
| coffee, and come back to a useable newly installed package.
| Macports felt like it could throw errors because Venus was
| in retrograde sometimes.
| anarticle wrote:
| Not sure why the subtweet, but I'll guess it was macports,
| which in my experience was not as fun or easy as brew.
| frollogaston wrote:
| MacPorts is still around, and that's what I use.
| nottorp wrote:
| I doesn't have to do anything better. It's in Rust and that
| should be the only reason you need to switch.
| benatkin wrote:
| 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)
| adamnemecek wrote:
| Also in Rust, haha.
| benatkin wrote:
| I finally looked up the GitHub repo found some context about
| the website: https://github.com/pkgxdev/pantry/issues/5358
| mimischi wrote:
| AI slop, but also for all the imagery. The early 00s called,
| and want their large icons back. This is the worst landing page
| I've seen--almost screams crypto-scam.
| no_wizard wrote:
| What's the deal with the cautious warnings? Is homebrew being
| replaced by software developed using a "vibing coding" or what
| have you?
| benatkin wrote:
| if you see the issue I linked, there are a lot of thumbs up /
| thumbs down in the comments, it's not just me =)
| no_wizard wrote:
| I think I lack context enough that even the link doesn't
| make it very clear to me.
| joshuaturner wrote:
| Oof. Those AI images really harm the credibility of the package
| manager.
| benatkin wrote:
| 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.
| Zambyte wrote:
| 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...
| schnable wrote:
| Is this the guy who was complaining that he didn't get hired
| by Google even though he made brew? Maybe there were
| personality issues at play...
| Zambyte wrote:
| I checked out his X account and yep, that's the guy.
| woodruffw wrote:
| This has nothing to do with Homebrew. It's a different
| project.
| Zambyte wrote:
| Yeah, but the relationship makes my spidey senses tingle
| even if it's not accurate.
| woodruffw wrote:
| Consider re-attuning your spidey senses away from
| inaccurate things!
| woodruffw wrote:
| Creator, not current maintainer. Homebrew is currently
| maintained by over a dozen people, myself included.
| elcritch wrote:
| > 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.
| bhouston wrote:
| 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.
| woodruffw wrote:
| FWIW: a longstanding limitation for parallel downloads within
| Homebrew isn't architectural (it's not too hard to add!) but
| structural with respect to Homebrew's download sources:
| GitHub and others are _very_ gracious with the amount of
| traffic we send their way, and we don 't want to overtax
| services that have other major consuming parties.
|
| (This is a perverse countereffect: small projects can make
| performance decisions that Homebrew and other larger projects
| can't make, because they don't have a large install base that
| reveals the limitations of those decisions.)
| bhouston wrote:
| > FWIW: a longstanding limitation for parallel downloads
| within Homebrew isn't architectural (it's not too hard to
| add!) but structural with respect to Homebrew's download
| sources
|
| I have heard that before.
|
| Hmm.... I wonder if you can get away with not doing
| parallel downloads, but just keep the sequential downloads
| going in the background while it is installing a package?
| It is the pause in downloads during an install that I find
| is the main slow down in brew.
| woodruffw wrote:
| > I wonder if you can get away with not doing parallel
| downloads, but just keep the sequential downloads going
| in the background while it is installing a package?
|
| I could be wrong, but I believe multiple people,
| including maintainers, have looked into exactly that :-)
|
| (I also need to correct myself: there is some work
| ongoing into concurrent downloads[1]. That work hasn't
| hit `brew install` yet, where I imagine the question of
| concurrent traffic volume will become more pressing.)
|
| [1]: https://github.com/Homebrew/brew/issues/18278
| hackingonempty wrote:
| P2P protocols like BitTorrent are made for this kind of
| problem.
| woodruffw wrote:
| Sure. There's also a reason no major OSS packaging
| ecosystem uses these protocols: the only thing worse than
| a slow distribution scheme is an _unreliable_ one.
| Combine that with the (reasonable) lack of a reward
| scheme for seeding an OSS packaging ecosystem, and you
| have a distribution mechanism that 's significantly more
| brittle than the current "throw a lot of bandwidth at it"
| approach.
|
| (Among other technical challenges, like updating the P2P
| broadcast for each new bottle.)
| hackingonempty wrote:
| I think you are misinformed as BitTorrent, for instance,
| is much more reliable than https alone. The reward scheme
| is built in already: the client uploads while it's
| downloading and installing and prioritizes the clients it
| is downloading from. At worst, the reliability and
| performance are the same as the web seed.
|
| Generating additional metadata at bottle build time
| doesn't appear to be much of a technical challenge
| either.
| woodruffw wrote:
| > The reward scheme is built in already: the client
| uploads while it's downloading and installing and
| prioritizes the clients it is downloading from.
|
| These are asymmetric: brew runs at a point in time, and
| most people decidedly _do not_ want brew running in the
| background or blocking while leechers are still being
| serviced. They want it to exit quickly once the task at
| hand is done.
|
| > Generating additional metadata at bottle build time
| doesn't appear to be much of a technical challenge
| either.
|
| That's not the challenge. The challenge is distributing
| those updates. My understanding is that there's no
| standard way to update a torrent file; you re-roll a new
| file with the changes. That means staggered delivery,
| which in turn means a long tail of clients that see
| different, incompatible views of the same majority-equal
| files.
| bhouston wrote:
| > My understanding is that there's no standard way to
| update a torrent file; you re-roll a new file with the
| changes.
|
| You should only re-distribute the original file that was
| downloaded and thus one can just advertise the original
| torrent that was downloaded.
|
| But as you said earlier, brew is a point in time command
| and this BitTorrent solution would only really work if
| brew switched to an always-on service. And I am not sure
| that many people want to do that, although I am sure some
| would.
| hackingonempty wrote:
| > These are asymmetric: brew runs at a point in time, and
| most people decidedly do not want brew running in the
| background or blocking while leechers are still being
| serviced. They want it to exit quickly once the task at
| hand is done.
|
| Yes, brew exits when it is done installing, nothing would
| need to change about that if you used BT protocol to
| speed up downloads. I'm sure you do have some helpful
| users who would volunteer to seed their cache though,
| which would become feasible.
|
| > That's not the challenge. The challenge is distributing
| those updates.
|
| The metadata goes in the formula alongside the current
| metadata (URLs and hashes.)
| Lammy wrote:
| > My understanding is that there's no standard way to
| update a torrent file; you re-roll a new file with the
| changes.
|
| Kinda. You do create a new torrent, but you distribute it
| in a way that to a swarm member is functionally
| equivalent to updating an old one. Check out BEP-0039 and
| BEP-0046 which respectively cover the HTTP and DHT
| mechanisms for updating torrents:
|
| https://www.bittorrent.org/beps/bep_0039.html
|
| https://www.bittorrent.org/beps/bep_0046.html
|
| If that updated torrent is a BEP-0052 (v2) torrent it
| will hash per-file, and so the updated v2 torrent will
| have identical hashes for files which aren't changed:
| https://www.bittorrent.org/beps/bep_0052.html
|
| This combines with BEP-0038 so the updated torrent can
| refer to the infohash of the older torrent with which it
| shares files, so if you already have the old one you only
| have to download files that have changed:
| https://www.bittorrent.org/beps/bep_0038.html
| woodruffw wrote:
| That's very cool! That addresses the basic update issue,
| although I would be surprised if there was a production-
| ready Ruby library for torrents that included these. The
| state of HTTP(S) in Ruby is sad enough :-)
|
| (There's also still the state/seeding problem and its
| collision with user expectations around brew getting
| faster, or at least not any slower.)
| Lammy wrote:
| I agree with you about package manager usage patterns
| being a poor fit for seeding by end users. I definitely
| wouldn't want my computer to participate.
|
| I could see institutional seeders doing it as a way to
| donate bandwidth though, like a CDN that's built into the
| distribution protocol instead of getting load-balanced to
| Microsoft's nearest PoP when hitting a GitHub `ghcr.io`
| URI like Homebrew does today. Or even better, use that as
| an HTTP Seed (BEP-0019) to combine benefits of both :)
|
| https://www.bittorrent.org/beps/bep_0019.html
| elcritch wrote:
| Good points, background downloads would speed it up.
|
| And the language doesn't have much to do with that. This
| project looks to be someone just toying around with Rust or
| their own PM. Props for that, but the headline has extra
| implications on HN.
|
| I recently rewrote a big portion of Atlas [1]. It's a Nim
| based dependency manager that clones Nim packages to a
| `deps/` folder. Initially I was worried about using reference
| types, etc, for performance reasons. It's a general habit of
| mine. Then I remembered that stuff would be negligible
| compared to the download times and git overhead. Well aside
| from the SAT solver.
|
| 1: https://github.com/nim-lang/atlas
| lopatin wrote:
| Ruby isn't web scale. Rust is web scale.
| MrBuddyCasino wrote:
| Homebrew is dog-slow. If this becomes yet another Rust tool
| that is 10x faster than the one that it replaces: great.
| bhouston wrote:
| I use homebrew constantly but the only part I find slow is
| the custom installations of the software and the lack of
| downloading while installing? Neither of these is related to
| the implementation language.
|
| What part of the home brew experience do you find slow?
|
| eg...
|
| % time brew upgrade
|
| brew upgrade 0.75s user 0.16s system 68% cpu 1.337 total
|
| % time brew list
|
| brew list 0.01s user 0.02s system 57% cpu 0.054 total
| rafram wrote:
| Homebrew is 99% IO-bound and this will be too. Installing
| (prebuilt) packages doesn't require much logic. If this tool
| supports parallel downloads, it _will_ be 10x faster than
| Homebrew, but it won 't have anything to do with the
| language. The issue is finding a hosting provider willing to
| be DDOS'd for the good of the open-source community.
| MrBuddyCasino wrote:
| > _If this tool supports parallel downloads, it will be 10x
| faster than Homebrew, but it won 't have anything to do
| with the language._
|
| If this is true, why are the Rust tools, on average, so
| much faster than the JS (or whatever) tools they replace?
|
| Hint: the answer hasn't _just_ to do with the theoretical
| technical merits of the underlying platform, but also what
| type of developer they attract.
| frollogaston wrote:
| Do you have an example of a faster Rust tool that
| replaced an IO-bound JS tool? The toolchain ones that got
| Rust replacements were CPU-bound afaik.
| IshKebab wrote:
| Hmm I'm sure people said that about Pip before uv came
| along and was literally 10x faster.
|
| To be fair I haven't noticed Brew being as tediously slow
| as Pip. Maybe I just use it way less.
| woodruffw wrote:
| There are two things that work in `uv`'s favor (which, to
| be clear, is an incredible tool that I'm a big fan of):
|
| 1. Python packaging, unlike Homebrew, _does_ have a
| compute-heavy phase in the form of dependency resolution.
| `uv` can make significant gains over `pip` in that phase.
|
| 2. `uv` performs parallel downloads and other operations,
| in part because of Rust's fearless parallelism.
|
| Homebrew doesn't really have (1), since resolution is
| just a linearization of the dependency tree. And
| parallelism of downloads in (2) poses a problem for
| Homebrew that's been mentioned in other threads (whereas
| parallelism is not a significant problem for PyPI's CDN-
| fronted distribution).
| frollogaston wrote:
| Python should be able to do parallel downloads at least,
| albeit having the overhead of multiple OS threads unless
| you're using asyncio.
| woodruffw wrote:
| Yep. The limitation in pip is architectural, not on
| Python's own side. However, there's been some progress
| there recently[1].
|
| [1]: https://github.com/pypa/pip/issues/825
| larusso wrote:
| 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.
| skydhash wrote:
| I loved macports, mostly because I wanted to create a new user
| account for a project and got bitten with the permissions thing
| by homebrew. I don't mind typing sudo.
| azinman2 wrote:
| 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.
| motorest wrote:
| > 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.
|
| This. There's a wave of projects whose only value proposition
| is this vacuous "let's reinvent the wheel in Rust" sales pitch,
| where nothing of value is proposed beyond throwing around the
| Rust buzzword.
| IshKebab wrote:
| Is it really necessary to restate the advantages of rewriting
| in Rust in every such project? Compared to Ruby programs Rust
| programs are faster, more robust, more maintainable, and
| easier to install. That's pretty much the same for any Rust
| rewrite (e.g. uv).
|
| It would be interesting to know if there are other goals
| though, e.g. UX improvements.
| azinman2 wrote:
| The speed of homebrew has never been limiting factor (for
| me). I think there are far more important factors in what's
| maintainable or not than language, and homebrew is very
| easy to install.
|
| There has to be more important reasons to replace a mature
| widely use project like homebrew.
| runjake wrote:
| 1. I thought "Sapphire is a next-generation, Rust-powered
| package manager inspired by Homebrew" covered it pretty well.
|
| 2. It's a personal project.
|
| 3. It's explicitly declared as alpha software.
| frollogaston wrote:
| Yeah, the HN title was editorialized as a Homebrew
| "replacement," which may be ticking people off.
| azinman2 wrote:
| " Sapphire is a next-generation, Rust-powered package manager
| inspired by Homebrew"
|
| Doesn't tell me how it differs. What makes this next
| generation? Just the programming language?
|
| If it's just a for fun personal project that no one else is
| supposed to use, I'm not sure why it's on HN.
| ethan_smith wrote:
| Agreed - without clear performance metrics or feature
| differentiation in the README, potential users have no
| compelling reason to switch from a mature ecosystem like
| Homebrew to an alpha-stage alternative.
| alexykn wrote:
| 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.
| jrochkind1 wrote:
| 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?
| dijit wrote:
| I say this from ignorance, but coming from a lineage of linux
| package managers; brew must be doing _something_ wrong - and
| upon immediate introspection I doubt that its language
| specific.
|
| The performance of apt/dnf in comparison is surreal; but dnf
| (or at least yum, its predecessor) is written in Python;
| which has even worse performance characteristics than Ruby.
|
| Clearly something is wrong, I wonder how different they are
| architecturally.
| woodruffw wrote:
| Have you tried Homebrew in the last year or so? I think a
| lot of people have an impression of Homebrew's performance
| from the "bad old days," i.e. back when Homebrew had to
| evaluate every single local formula file to perform any
| operations at all.
|
| (There's still low handing fruit, but it's not like it was
| a few years ago where `brew list` took seconds to run. It
| now runs nearly instantaneously for me locally, like most
| of the other happy path commands.)
| dijit wrote:
| Yes, I use it on my daily driver, and it's at least two-
| orders of magnitude slower than apt.
|
| However, the speed increase coincided with my upgrade to
| an M-Series laptop, so it's possible I just presumed
| there was a significant hardware speedup in the time
| we're talking about.
| amarshall wrote:
| One big difference is that apt and dnf are both binary
| package management systems, whereas Homebrew is a source-
| based build system with binary packages ("bottles") added
| on top.
| alexykn wrote:
| Building from source, obviously, will never be really that
| much more performant as it mainly relies on the underlying
| build systems and things like ninja, cmake, cargo etc. are
| usually optimized very very well.
|
| Thanks to rust just being (slightly, significantly? no idea
| about ruby's speed) faster + concurrent downloading & pouring
| of bottles, most "regular" formula installs feel a good bit
| faster than brew already. Mainly noticeable when installing
| multiple formulae at once.
|
| Casks, especially those with pkg installers, seem to profit a
| bit less here.
|
| Performance was a reason, not the main one though, like I
| said I wanted and still want, to build a declarative package
| + system managing solution on top. The idea was to get into
| rust with that. Imo having the base written in the same
| language instead of wrapping commands also gives more
| flexibility there.
|
| Another reason is that I never liked the way brew looks and
| feels. Right now the ui/ux for Sapphire is far from finished,
| more like a clusterf*k and only the search command really
| looks the way I want it. Aiming for something modern, clean
| and information rich without beeing overly verbose. I really
| like dnf5 and what AerynOS is doing and will probably take
| some inspiration there.
|
| Like mentioned, Bottles and Casks should be 100% doable and
| that would cover most package needs on macOS, I do not see
| why I should also define a new repo and packaging ecosystem
| when such a big and popular one exists.
|
| Source build capability will probably stay(for easy
| integration of source building in the system management part
| later) but not be focused on brew formulae as the ruby dsl
| would be a horror to parse.
|
| Well and sh*t I am not trying to compete really. This is the
| first time building something with rust and I really really
| had no idea what a giant never ending rabbit hole macOS
| package management is and how massive and complex Brew is.
|
| This went from should I to can I pretty quick for me xD
| mudkipdev wrote:
| I would be interested to see more declarative package
| managers for macOS, I was looking for something similar
| just a few days ago.
| nicoburns wrote:
| Perhaps you could embed something like
| https://github.com/artichoke/artichoke to run the Ruby scripts
| for compatibility.
| adamnemecek wrote:
| Please don't.
| alexykn wrote:
| Looked at that. I do not really think implementing something
| like artichoke or rutie would be a good idea. I do not want
| my project to become overly bloated and to achieve my real
| goal of a declarative system management thing I think
| sticking to bottles (that cover almost all formulae thanks to
| the amazing homebrew community) and casks, getting those to
| work 100% is the better approach. Thank you for the
| suggestion though!
| yincrash wrote:
| One thing that Homebrew does not do easily is to easily allow
| for creation of universal libraries and binaries -
| https://github.com/orgs/Homebrew/discussions/4647
|
| Maybe that could be a place where sapphire differentiates?
| Scramblejams wrote:
| Cool project, good luck with it!
|
| If I may surface one use case: Several years ago I had to
| manage a bunch of Macs for CI jobs. The build process (Unreal's
| UAT) didn't support running more than one build process at a
| time, and Docker was really slow, so I'd hoped to use different
| user accounts to bypass that and get some parallelization
| gains. Homebrew made that very difficult with its penchant for
| system-wide installs. So a feature request: I'd love to see a
| competitive package manager that limits itself to operating
| somewhere (overridable) in the user's home directory.
| alexykn wrote:
| Initial idea for this really came from my dayjob too, we have
| macs but no way to centrally manage them. The client / server
| part for the declarative system manager I want to build on
| top of this is quite far out yet though. At least several
| months
| amarshall wrote:
| Nix effectively has per-user packages, but it's hard to read
| into your full use case from your comment.
| watermelon0 wrote:
| IIRC the main reason here is that brew path is hardcoded
| during the build process of packages, which means that you
| wouldn't be able to use bottles.
|
| I didn't check, but there is a chance that path is also
| hardcoded in (some) formulae, so even building from the
| source might not help here.
| scribu wrote:
| You could run the build process with chroot or inside
| Docker, so that the hardcoded paths actually resolve to a
| designated subdirectory.
| mananaysiempre wrote:
| Incidentally, that's what is usually done in Nixpkgs in
| similar situations when there's no better alternative,
| see buildFHSEnv et al.
| benwaffle wrote:
| oh, I guess this is why the nix installer creates 32 macOS
| users called _nixbld$N
| homebrewer wrote:
| It's explained in the documentation.
|
| https://nix.dev/manual/nix/2.25/installation/multi-user
| 3np wrote:
| > probably settle for automatic build system detection based on
| archive structure there
|
| Please add knobs for the end user to manually configure this
| per package and global default before adding autodetection. As
| a user to is very frustrating to have to patch the package
| manager to override some well-intentioned automagic which
| didn't consider my setup or dig through sources to uncover some
| undocumented assumption. yarn is a cautionary example.
| alexykn wrote:
| I'll add manual override flags and also let users not only
| build from source from formulae but any dir on their machine
| they want, only makes sense
| samhclark wrote:
| You mentioned a declarative package manager for Mac. I've
| really liked using Homebrew Bundle [1] over the last couple
| years. It's about the level of declarative that I've wanted and
| has made it really easy to bootstrap new laptop or VM (since it
| also works on Linux). The format for a Brewfile was pretty easy
| to figure out.
|
| The way I ended up using it was that `brew install` would
| temporarily install something, without adding it to my
| Brewfile. And a little `brew add` wrapper would add the package
| to my Brewfile to keep it on the system permanently. That part
| with the wrapper could have used some love and would be a nice
| fit for a new brew-compatible frontend IMO. Maybe you could
| expand on that for Sapphire, if that also scratches your
| declarative itch?
|
| [1] https://docs.brew.sh/Brew-Bundle-and-Brewfile
| hk1337 wrote:
| 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
| runjake wrote:
| For the last 5 years (since Apple Silicon was released),
| Homebrew has installed to /opt/homebrew by default.
| mort96 wrote:
| No, it only does that _on Apple Silicon_. To this day, if you
| run the latest Homebrew on an Intel Mac running the latest
| macOS, it will install to /usr/local.
| runjake wrote:
| The parent indicates in a comment that they use an Apple
| Silicon Mac[1].
|
| I don't see a lot of engineers running Intel Macs anymore.
| I haven't seen _any_ engineers who still use an Intel
| model, myself, and for quite some time. Especially when
| there are Apple Silicon options for well under $1,000 that
| highly outperform the Intel models.
|
| 1. https://news.ycombinator.com/item?id=43267210
| mort96 wrote:
| This looks like a fun little project, nice work!
|
| I'm not a big fan of keeping the Homebrew terminology though. I
| never know what a formula, keg, cask, cellar, tap or bottle is.
| Why not keep to the standard terms of package and repository etc?
| I don't know beer brewing terminology or how beer brewing is
| analogous to package management, and I honestly wish that it
| wasn't something which my tools expect me to learn.
| seumars wrote:
| Agreed. Come to think of it Homebrew has pretty bad ergonomics
| in general. What i want is an overview of compiled binaries,
| where they are, and what their versions are. That's it.
| alexykn wrote:
| I will probably change the terminology at some point for this.
| For initially building it it is way easier to keep them the
| same though as trying to understand brew itself (at least for
| me) isn't so straight forward. It's a massive project
| moritzwarhier wrote:
| Kudos for your humility.
|
| I'd agree that the current homebrew terms are inappropriately
| whimsical and hard to grasp, but you are right in your
| intuition and goal, IMO.
|
| That is, taking care of the gears first and then carefully
| adjusting the public API.
| bartvk wrote:
| Nowadays, normal users don't need to know. They just "brew
| install <name>".
| mort96 wrote:
| I disagree. I need to understand what Homebrew means when it
| says that a cask is keg-only or whatever, or what it means to
| tap a cellar or whatever when I wanna add repositories. The
| documentation and '--help' output also refers to the beer
| brewing terms, not standard package management terms.
| alexykn wrote:
| Some reason I just died laughing. Really struggled with all
| that stuff while building this, just seemed to make no
| sense in the beginning. Maybe I should do
| /opt/sapphire/cave, opt/sapphire/cove and
| opt/sapphire/quarry for mine haha
| QuercusMax wrote:
| As an experienced homebrewer, I don't think knowing about
| making beer makes it any clearer to me. Why do I need to
| install Docker from a Cask? Oh, it's because on Mac, a Cask is
| actually a Mac package (DMG or PKG or something). It's just
| arbitrary beer-flavored terminology.
|
| No different than the Windows registry, which apparently uses a
| honeybee / hive metaphor because some Windows dev hated bees
| and their teammates liked trolling them.
| Lammy wrote:
| That one was non-obvious to me as well, but I am sympathetic
| to the need to call them _something_. Not trying to bikeshed,
| but if there was a single obvious name for them then you
| would have used it instead of "DMG or PKG or something".
| Philpax wrote:
| Please kill the Homebrew terminology if you can! Its
| idiosyncratic names are the bane of my existence; it might have
| been cute in 2010, but it's frustrated me ever since.
|
| I don't want to memorise their twee names; I'd much rather the
| name tell me what the entity / operation does by itself.
| ok_computer wrote:
| Cute names for standard things is one of my software bug bears,
| i.e. pet peeves, i.e. annoyances. Ruby gems and rust crates and
| something something beans. It is cute jargon and it annoys me
| to hide the definition inside a language specific terminology.
| mort96 wrote:
| It's actually one of the main reasons I landed on using Axum
| for a web server in Rust instead of Rocket: I got fed up with
| the additional level of semantic indirection the cutesy names
| added. I didn't wanna burn brain cycles decoding what it
| means to install fairings or launch rockets, or what
| "ignition" means contra "liftoff". I like boring names for
| things.
| kergonath wrote:
| > I like boring names for things.
|
| It's not that I _like_ boring. But I _really_ like
| descriptive names. I have other things to do with my time
| than figuring out what the hell a cask, a tap, or a bottle
| is. Like solving the problem that requires the damn
| software.
| atonse wrote:
| Yes! A thousand times yes. Homebrew terminology makes
| absolutely zero sense whatsoever and I find it irritating when
| I encounter it every now and then (like when a package says tap
| something and then install it blah blah)
|
| I wish they'd just call them binaries, macOS packages,
| packages, gui-packages, etc.
|
| To be clear, all those words are also jargon but they're
| reusable concepts across software.
| woodruffw wrote:
| With my Homebrew hat on, but not speaking for others: I think
| this is pretty cool, and demonstrates something that we've
| discussed indirectly for years.
|
| At its core, there are really two parts to Homebrew:
|
| 1. There's the client side, i.e. `brew`, which 99.9% of users
| stick to happy paths (bottle installs, supported platforms)
| within. These users could be supported with relative ease by a
| small native-code installer, since the majority of the work done
| by the installer in the happy path is fetching bottles, exploding
| them, and doing a bit of relocation.
|
| 2. There's _literally everything else_ , i.e. all of the
| developer, repository, and CI/CD machinery that keeps homebrew-
| core humming. This is the largely invisible infrastructure that
| makes `brew install` work smoothly, and it's _very_ hard to RIIR
| (in a large part because it 's tied heavily to the formula DSL,
| which is arbitrary Ruby).
|
| (1) is a nice experimental space, because Homebrew does (IMO) a
| decent job of isolating the client-facing side from the
| complexity of (2). However, (2) is where the meat-and-potatoes of
| packaging happens, and where Homebrew's differentiators really
| lie (specifically, in how easy it is to contribute new packages
| and bump existing ones).
|
| Edit: Another noteworthy aspect here around performance: I
| mentioned this in another comment[1], but parallel downloads of
| things like bottles and DMGs is not an architectural limitation
| of Homebrew itself, but instead a conscious decision to trade
| some install speed for courtesy towards the services we fetch
| from (including GitHub itself). Smaller projects can sidestep
| this because they're not directing nearly the same degree of
| volume; I think this project will discover if/when its volumes
| grow that it will need to serialize downloads to avoid being
| throttled or outright limited.
|
| [1]: https://news.ycombinator.com/item?id=43765605
| IshKebab wrote:
| > but parallel downloads of things like bottles and DMGs is not
| an architectural limitation of Homebrew itself, but instead a
| conscious decision to trade some install speed for courtesy
| towards the services we fetch from
|
| That doesn't make sense. As you say you're directing a huge
| volume of traffic so it makes no difference exactly when a user
| downloads a byte. It all gets smeared out. Only the total
| amount of data matters and that is unaffected by parallelism.
| woodruffw wrote:
| > As you say you're directing a huge volume of traffic so it
| makes no difference exactly when a user downloads a byte. It
| all gets smeared out.
|
| Homebrew's traffic pattern is not a uniform distribution.
| Package updates go out, and users download those packages in
| structured ways: there are spikes for MDM-managed Homebrew
| installations, spikes for cronjobs and CI/CD systems, spikes
| at 9AM on different coasts when developers sign into their
| machines, etc.
|
| (How much this matters is also not uniform: it matters
| somewhat less for GitHub Packages - they should have a hefty
| CDN - and it matters somewhat more for Casks, which tend to
| be large DMGs hosted on individual servers.)
| xiphias2 wrote:
| It's not _just_ the infrastructure that is awesome for
| homebrew. The help I got from the team, answering in real-time
| when I didn't know how to get through the CI bugs is amazing.
| It's the boring maintainence work that makes it so special for
| me.
|
| I also feel that there could be a lot of automation in the
| backend part, catching bugs early (maybe even on local machine
| before CI run) for example.
| chrisweekly wrote:
| > "it's very hard to RIIR"
|
| RIIR - "Rewrite It In Rust" (maybe obvious in context? sharing
| in case not)
| selkin wrote:
| Homebrew sure has room for improvement, as most software does,
| and I appreciate every effort to replace and renew what we have
| with something better. But my own grievances with Homebrew isn't
| with the codebase itself.
|
| What discourages me from using Homebrew is the intent and the
| mindset of its developers and packagers, who, I think, see their
| goal building an "unstable" distribution, as Debian defines it:
| "[a distribution that] is run by developers and those who like to
| live on the edge".
|
| I am not blaming the Homebrew developers for building a Sid
| rather than Bookworm. Some people want just that. Heck, I used to
| run Debian Sid myself, but have lost my patience for maintaining
| my own computers since: I am kept busy enough by fixing the
| software I write, I don't want to spend more time fixing software
| I did not.
| jamesgeck0 wrote:
| If I understand correctly, running a Debian-style stable repo
| would essentially require forking all distributed software and
| backporting security fixes to them.
|
| With many macOS users coming from a different communities than
| Debian users, I really wonder how well that would go over with
| the folks whose software was being distributed.
| selkin wrote:
| Caveat lector, as I didn't collect the data to back this, but
| I would be extremeley surprised to find more than a few dozen
| of non-cask packages in Homebrew that contain Macintosh only
| software.
| frollogaston wrote:
| I mainly disagree with the Homebrew stance on sudo/root. They
| claim it's better to install everything under a user dir, but
| 10% of the time that doesn't work for whatever reason, and tons
| of users have screwed up their permissions trying to fix it. No
| other package manager has this issue.
| selkin wrote:
| I am not too fond of this design for reasons of privilege
| separation and FHS-alignment, but can accept it as most
| Homebrew users don't have their Macintosh computers used by
| multiple people.
| frollogaston wrote:
| My machine is single-user, problem is some things require
| root. Maybe they _shouldn 't_ according to Homebrew's
| stance on permissions, but idk, I'm working with what I've
| got.
| selkin wrote:
| Can you give a concrete example?
|
| I know why certain software has be run with root
| privileges, but it's a bit hard for me to come with a
| reasonable scenario where a software would fail to run
| properly when installed to a directory that is owned by
| the same non-root user that launches that software.
| frollogaston wrote:
| The symptom was something like
| https://stackoverflow.com/questions/16432071/how-to-fix-
| home... , which btw has a terrible accepted answer. I
| forget the root cause (no pun intended), possibly some
| bad interaction with stuff I installed outside of
| Homebrew. It's also possible I did something wrong, but
| even then there's something to be said about so many
| users having the same problem uniquely with Homebrew.
|
| Lemme try to repro again when I'm home.
| mort96 wrote:
| I would've been alright if they actually installed stuff in a
| user dir under the user's home folder, but it's insane to
| have a system-wide /opt/homebrew owned by whatever user
| happened to run the installer. Very icky.
| selkin wrote:
| It is possible to install Homebrew itself and the software
| it packages under your home folder[0], though that
| configuration is not officially supported.
|
| This is how I install Homebrew when I have to, and so far
| the only issue I ran into is that binary packages are often
| tagged as installable only to Homebrew's default folder, so
| Homebrew had to built the to-be-installed software from
| source instead, resulting in it taking longer and the
| computer fans spinning louder.
|
| [0] https://docs.brew.sh/Installation#untar-anywhere-
| unsupported
| oulipo wrote:
| Cool, but why not use https://mise.jdx.dev/ ?
| Alifatisk wrote:
| Because I haven't heard of it until now?
| IshKebab wrote:
| That's a totally different tool. Brew is a generic package
| manager that installs ... basically everything. Mise is
| specifically for managing compilers and associated tooling. You
| can't install libgmp or mplayer with Mise.
| trallnag wrote:
| I'm still not sure if I like the fact that the package
| management part of mise relies on a bunch of third-party
| package managers / repositories like asdf, aqua,...
| commandersaki wrote:
| If this provided support for multi-user setup without the user
| switching gymnastics of homebrew, then I'd be interested.
| hnarayanan wrote:
| I'm really happy with my MacPorts.
| ansc wrote:
| I'm really rooting for this. I can't wait for Homebrew
| replacements, what a pain it is.
| monoid73 wrote:
| same here. brew's been great historically but it's gotten
| bloated and kinda slow. curious to see if sapphire can keep
| things lean without sacrificing compatibility.
| kccqzy wrote:
| What is your pain point? If you don't elucidate your pain
| point, whatever the replacement is it might copy over that pain
| point.
| frollogaston wrote:
| I just want the equivalent of `sudo apt-get install` on Mac, with
| the same exact commands.
| jen20 wrote:
| The thing you want then is `fink`, which literally uses dpkg
| and apt.
| frollogaston wrote:
| That sounds like what I want. Seems to only have "wip"
| support for the newer macOSes though. I also remember using
| the Debian packager on iPhone back in the golden age of
| jailbreaking.
| alexykn wrote:
| Anyway, please do not expect progress to be too rapid. I have a
| full time job and do most work on this on weekends. I fully
| intend to make it a stable, "finished" (as much as this is
| possible in software) thing, it will take a while though. If
| anyone want's to help out I do open the bugs I find as Issues to
| keep track and give people an idea of things that do not work.
| Good Night!
| whywhywhywhy wrote:
| Consider rebranding to a 4 letter name or even better a 3 letter
| one.
|
| I know it sounds dumb but uv was smart to go shorter than pip and
| sapphire feels heavier than brew no matter what it does after
| typing that.
| jdeaton wrote:
| Yeah i vote it should be rebranded "why"
| alexykn wrote:
| command: why install htop, -> install start: because you wan'
| it -> done: you got it
|
| Something like that you mean?
| Asraelite wrote:
| I would love if the way to respond "yes" to the CLI is "why
| not"
| Ringz wrote:
| Why not.
| chucksmash wrote:
| Perhaps _why?
| alexykn wrote:
| I know, probably will, also feel typing out sapphire for the
| command all the time is annoying + sapp would be weird. For me
| technical implementation comes first though. I'll do that when
| something comes to mind
| syvolt wrote:
| 'sph' doesn't seem too bad though.
| cfreksen wrote:
| This reminds me of the PIK image format (a precursor to
| JPEG XL) whose name happens to be a word for penis in some
| languages[0]. In the present case "SPH" is a kink/fetish
| term meaning "Small Penis Humiliation"[1]. I don't know how
| many people would think of that, though.
|
| I am not sure if the lesson is to try harder to avoid
| offence, or live with the fact that words can have multiple
| meanings and we can be "professional" enough to ignore some
| of those meanings in some contexts.
|
| [0]: https://github.com/google/pik/issues/6
|
| [1]: https://www.urbandictionary.com/define.php?term=sph
| morning-coffee wrote:
| Maybe `grog` (or `grug` from https://grugbrain.dev)? :)
| maartn wrote:
| Please give it an easier command name than 'sapphire' if you want
| to win people over to use it. Double in size and three times as
| hard to remember (or type) than 'brew'. Even cli peeps are still
| just people
| selkin wrote:
| https://en.wikipedia.org/wiki/Alias_(command)
| ARandomerDude wrote:
| Suggestion: create a Goals/Motivation/Rationale section in the
| README. What are the problems with Homebrew you're trying to
| solve? Why should a prospective user install and try this tool
| instead of staying with Homebrew?
| moonlion_eth wrote:
| wen linux
| mrbonner wrote:
| I used to be a big fan of Homebrew but switch to Nix about 2
| years ago. For the most part, it works great with home manager
| for me. Many tools can be installed with breeze just like breeze
| albeit a bit quicker. The critical thing for me is that Nix
| doesn't polute my Mac environment like Brew does. But, I admit
| that this is just for tools. For dev environment I usually just
| fall back to the language specific methods like cargo, uv or npm.
| nicce wrote:
| Some GUI-based applications tend to require too much hassle
| with Nix so I personally install those with brew. But I still
| use home manager on top of everything.
| cantrecallmypwd wrote:
| This isn't a HB replacement, it's just using HB binaries. It
| doesn't replace HB at all. HB and this aren't full package
| managers when they don't officially or technically support
| building from source or working independently of another
| project's infrastructure.
|
| A decent full package manager would support a simple, shell-like
| DSL like say Alpine or Arch, concurrent and parallel phases (such
| as downloads/builds/installs), multiple versions, reproducible
| builds, building from source, build acceleration, security
| auditing, patch management, and package cryptographic signatures
| (not hashes or signing of hashes).
|
| Nix is theoretically amazing but the barrier-to-entry and gotchas
| for popular use make it self-limiting. Simplicity in particular
| areas is a price that is often paid for popularity.
___________________________________________________________________
(page generated 2025-04-22 23:00 UTC)