[HN Gopher] Sapphire: Rust based package manager for macOS
___________________________________________________________________
Sapphire: Rust based package manager for macOS
Author : adamnemecek
Score : 420 points
Date : 2025-04-22 18:39 UTC (1 days 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?
| paradox460 wrote:
| Some of their leadership has been heavy handed with
| regards to unpopular decisions, like removing options
| from packages.
| 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.
| frumplestlatz wrote:
| Things improved a lot as homebrew relearned the design
| constraints and reasons why MacPorts made the decisions
| they did, and wound up adopting many of the same
| solutions.
|
| It was frustrating in the beginning to see so much
| marketing-driven shade being thrown from an ill-informed
| position.
|
| Obviously that wasn't you or the current maintainers of
| homebrew, and things have improved tremendously, but
| that's the era from which frustration like the
| grandparent post originates.
| frumplestlatz wrote:
| > 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.
|
| The worst part is that MacPorts already did the same
| thing, but used hardlinks to avoid the kinds of problems
| that emerge when (for example) `realpath` resolves a
| symlink to an unexpected versioned directory that's
| supposed to be an implementation detail.
|
| There was a _lot_ of FUD, dishonesty, and shallow
| understanding from the homebrew creators in the
| beginning.
| 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)
| int_19h wrote:
| There's also pkgsrc.
| frollogaston wrote:
| Mainly cause there's no curl | bash way to install :D and
| also it wants you to update it each time you update macOS,
| which iirc requires a reboot too
|
| I still use MacPorts though
| 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.
| frollogaston wrote:
| mxcl is the owner of this other project and also the
| original creator of Homebrew. Someone asked politely to
| remove a broken package from the list, mxcl gave an oddly
| combative response, then you see the rest.
| 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.
| benatkin wrote:
| If you search for "max howell google interview" it comes
| up, if you search for "max howell alphabet interview", no
| dice.
| 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!
| frollogaston wrote:
| Is there something horrible I'm missing here? It's just a
| not so well designed page of links to Github repos.
|
| Edit: Oh, the Github issue, yeah that's screwed up.
| 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
| woodruffw wrote:
| Yeah, something at the institutional layer makes sense.
| Thank you for sharing these links!
|
| (My skepticism around whether this makes sense for
| Homebrew might be obscuring it, but I'm generally quite a
| big fan of distributed/P2P protocols, and I strongly
| believe that existing CDN decencies in packaging
| ecosystems are a risk that needs mitigating.)
| hackingonempty wrote:
| There isn't an update issue. BitTorrent metadata are
| hashes, they get updated and distributed at the same time
| as the current URLs and hashes in the same file or maybe
| in a similarly named file right next to it in the same
| pull request.
|
| There is no state/seeding problem. The client downloads
| from the same https url as always but uses peers on an
| as-available basis to speed things up and reduce load on
| the origin.
| woodruffw wrote:
| The adjacent thread observes that there is an update
| issue, just one that has a technical solution.
|
| > The client downloads from the same https url as always
| but uses peers on an as-available basis to speed things
| up and reduce load on the origin.
|
| So some kind of hybrid scheme, which (to me) implies the
| worst of both worlds: clients are still going to hammer
| upstreams on package updates (since client traffic isn't
| uniform), _and_ every client pays a bunch of peering
| overhead that doesn't pay off until the files are "hot."
| In other words, upstreams still need to plan for the same
| amount of capacity, _and_ clients have to do more work.
|
| (The adjacent thread observes that none of this is
| necessary if CDNs or other large operators do this
| between themselves, rather than involving clients. That
| seems strictly preferable to me.)
| Kwpolska wrote:
| Homebrew packages are on the order of tens of megabytes.
| Plain old HTTPS downloads will complete faster than
| setting up a BitTorrent download.
|
| Using BitTorrent is also a great way to get banned from
| company-owned laptops.
| 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
| silverwind wrote:
| The slowness comes from its serialized downloads and
| package installations. If you install a thing that has 10
| dependencies, those 10 dependencies will serially install,
| likely taking many seconds.
| 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.
| fastball wrote:
| Why didn't you like the project if it was a better project by
| most definitions of what makes a good package manager? e.g.
| what did you want from a package manager besides 1. easy to
| install packages 2. readily updated packages.
| larusso wrote:
| macports had the cleaner packages. Macports created its own
| base library so that packages are not based on the macOS
| system libraries which managed to break them when doing
| system updates with brew or when you decided to stay longer
| on an older macOS version. That meant that packages from
| macports took longer to install and compile. That was from
| the time when bottles where not a thing yet. Brew was fast
| but unstable. In my opinion the inferior project won. But to
| brews defence they also addressed the issues over the years.
| Don't have any sources at hand but I remember a time when the
| brew project compared itself to macports and pointed out that
| their faster because they don't recompile all base libraries
| etc etc. And they had to realize that this wasn't a great
| idea. Now packages are practically split between different os
| versions. And different bottles are served depending which
| macOS version you run.
|
| Edit: And I got reminded that it was possible to run and
| install packages for and from multiple users. Brew took over
| /usr/local/bin and other /usr/local/homebrew for the running
| user. Managing a system with multiple users with brew was and
| still is hard. With macports you needed sudo like with most
| other package managers. The sudo less nature was a huge deal
| for its adoption. And now maybe a security risk if you ask
| me.
| pasc1878 wrote:
| macports eventually got an infrastructure that allowed
| binaries to be downloaded so no need for compilation on
| your local machine. SO the speed issue went away but too
| late as Hom,ebrew had gained the mind share
| sofixa wrote:
| > 1. easy to install packages 2. readily updated packages.
|
| Not OP, but I want my package manager to have good UX around
| package installs and updates, not it deciding to update a
| Python major version because a random small thing I'm
| installing it requests it.
| dur-randir wrote:
| Their maintainers have a rather dubious anti-user history
| with opt-out analytics and forced auto updates to said
| analytics.
| tannhaeuser wrote:
| Any idea what's up with MacPorts lately? Packages I needed to
| install were uncharacteristically broken or out of date which
| wasn't a thing ever since I switched from Fink ages ago. Apple
| used to use MacPorts internally and put resources into but they
| stopped doing so?
| larusso wrote:
| Didn't use it for quite some time now. I actually switched to
| nix packages for a while and was happy. Even worked in tandem
| with brew but I had a glibc issue on my shared Linux setup I
| could not resolve. I'm still on nixos on Linux and tested nix
| on macOS again with flakes. I'm not there yet to fully commit
| though.
| 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.
| koakuma-chan wrote:
| The issue with homebrew is not the programming language.
| The issue is homebrew itself. It takes forever to install
| packages, auto-updates without prompting you, etc. Also
| on my Mac it's been broken for years. It tries to auto-
| update and gets stuck forever.
|
| https://github.com/orgs/Homebrew/discussions/1177
| motorest wrote:
| I've been using homebrew for years and never did I ever
| experienced anything I would classify as "broken".
|
| The thread you posted is comical. How many times does
| anyone run homebrew per day? Or per week? And you still
| have people complaining about sub-second execution times
| of a list command? In an app whose happy flow is
| downloading hundreds of MB off the internet and save it
| to disk?
|
| Is this your argument for a major rewrite?
| koakuma-chan wrote:
| > Is this your argument for a major rewrite?
|
| A major rewrite in Rust.
| wolrah wrote:
| > Is it really necessary to restate the advantages of
| rewriting in Rust in every such project?
|
| I'm with you when the "source" project is C/C++ or
| something in that realm, but when we're coming from an
| already memory-safe language I do think some sort of
| explanation is helpful. I see Homebrew as more of a "glue"
| application where its own performance isn't exactly
| critical as it coordinates processes that are much slower
| so I don't really care if it's a bit faster.
| Kwpolska wrote:
| > faster
|
| By how much? Is homebrew really so slow, and used so often
| that an improvement would matter?
|
| > more maintainable
|
| [citation needed], especially for uv, which is a tool
| useful only for Python developers, so using a different
| language limits the pool of contributors.
| 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.
| dancek wrote:
| The author didn't submit it to HN, so criticizing it being
| on HN seems unfair to me.
|
| It's a cool piece of alpha-quality software. It may or may
| not be meant to be used, that's beside the point. As I see
| it HN isn't a platform for software recommendations, it's
| for discussing interesting geeky things. Which this
| definitely is, even if it was completely unusable today.
| pvg wrote:
| _Doesn't tell me how it differs_
|
| Not everything on HN has to come with a dissection and
| explanatory note - that's kind of the point of curiosity.
|
| _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._
|
| Those are totally fine on HN too.
| azinman2 wrote:
| Except the title (previously) said homebrew replacement.
| So when it doesn't say why/what, and there's no context,
| people are going to be confused.
| pvg wrote:
| Sometimes titles are slightly wrong. It's just not that
| big of a deal, most of the time. It's a messageboard in
| large part about the pleasure of finding things out
| rather than the grump of not everything being exactly as
| you expect.
| fastball wrote:
| #1 is a "what", not a "why"
| 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.
| WD-42 wrote:
| Another performance characteristic that used to piss me
| off when I used brew was that at least for one program,
| it had to invoke brew to launch. Something about finding
| a path. So that's an entire ruby interpreter starting and
| stopping just to (in this case) run a bash script.
| Horribly slow.
| woodruffw wrote:
| That's been fixed for at least a year! But yes, that used
| to be very slow, particularly when loading brew also
| meant loading every formula.
| KennyBlanken wrote:
| Yes, I have. It's slow as shit even on an M1. In the time
| it takes to install one brew package on an M1, a sudo apt
| update && sudo apt dist-upgrade has finished updating a
| dozen packages on a ten year old intel system with a SATA
| SSD.
|
| I _fucking hate_ homebrew.
|
| I hate the fact that the project still has the attitude
| of "sudo is le hard and we are le tired."
|
| The project people are assholes.
|
| The maintainers are often well behind current releases.
|
| It maintains a cache of every installed version for no
| good reason wasting ~10GB or more of my SSD space.
|
| When it breaks it's impenetrable trying to figure out how
| it broke, there's nobody to ask for help, the
| documentation sucks, and the fastest thing is just to
| wipe the whole fucking directory and start over.
|
| I could go on. I don't know a single person that likes
| using homebrew - it's just the package manager everyone
| resigned themselves to use.
| woodruffw wrote:
| > I fucking hate homebrew.
|
| > I hate the fact that the project still has the attitude
| of "sudo is le hard and we are le tired."
|
| > The project people are assholes.
|
| Have you considered that approaching us like this isn't
| productive and doesn't make anyone remotely interested in
| helping you?
| inferiorhuman wrote:
| I'm not the person you responded to, but I've mostly just
| accepted that homebrew is another paper cut that you get
| from using a Mac. If I post publicly about it I'm usually
| not looking for help.
|
| Years ago I worked with someone who strongly disliked
| brew because it leaned far too heavily on magic. I was
| okay with it because it seemed to work well. Brew still
| uses magic but now it just seems like I'm fighting it
| every single step of the way. I am le tired.
| woodruffw wrote:
| As a serious question, with no leading implied: what are
| you fighting about Homebrew? I can say with 100%
| earnestness that we're interested in improving the user
| experience, and we want to know where the pain points are
| for our users.
|
| Actually hearing about them (instead of just cursing at
| us) is genuinely helpful, and we genuinely appreciate it.
| 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.
| bobthecowboy wrote:
| FWIW, I believe DNF (as of 5?) is now written in C++.
|
| But as a long time Linux user who always has to use a Mac
| at work I've been consistently floored by how painful
| Homebrew is to use, to the point that for my latest corp-
| issued MacBook I switched to home-manager and I'm not
| looking back.
| 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.
| akdev1l wrote:
| In many cases the build output also has hardcoded paths
| unfortunately
|
| so doing `brew install` inside a container with the
| proper volumes it's not sufficient to fix the issue.
| Everything would have to run from within the container as
| well.
| 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
| JimDabell wrote:
| That would be fantastic. My bootstrap scripts already use
| bundle but it's easy to fall into config drift.
| NewJazz wrote:
| Just FYI you are describing a ports system, of which there are
| many. From macports, to alpine packages, to nixpkgs... Tons of
| research and automation in this area already. Would encourage
| looking at Nix and distri in particular. Many Nix packages can
| be built on/for macOS!
|
| https://nixos.org/manual/nixpkgs/stable/#preface
|
| https://michael.stapelberg.ch/posts/tags/distri/
| alexykn wrote:
| I know nix, did use nix-darwin for a while and actually
| integrated my own scripts called from the flake into setting
| up my system xD
| internet2000 wrote:
| Good luck. Homebrew hasn't cut it since they started
| disallowing custom compile flags, and making the user jump
| through hoops if they want anything slightly different.
| stevage wrote:
| Does the "casks" and "bottles" language imply that it's
| intended be compatible with Homebrew? That isn't made explicit
| in the description.
| MatthiasPortzel wrote:
| Yes, this is only a replacement for the Homebrew CLI. It
| doesn't have its own package repository and moreover it
| doesn't have the ability to build packages (yet)--it's just
| downloading and installing the binaries built by Homebrew.
| godelski wrote:
| This is awesome!
|
| Is there uv support?[0]
|
| One of my biggest gripes about brew is how they manage
| dependencies. The devs have a conflicting philosophy that
| creates bloat. Package maintainers must define settings,
| settings should always use the latest Python version. It makes
| no sense. Maintainers won't update unless things break so you
| got a bunch of Python versions running around. And it won't use
| system Python!
|
| Uv seems to provide an elegant solution for this. You can build
| a venv for each package and rust version will only have the
| specified deps. Since uv finds all your Python instances (and
| packages) and soft links them you have way less bloat and venvs
| become really useful. You can also use run and other tools to
| handle executables
|
| Plus is also rust so good synergy ;)
|
| [0] https://astral.sh/blog/uv
| Kwpolska wrote:
| You should only be using Homebrew for installing software
| that happens to be written in Python, not dependencies for
| your own Python projects. If you do that, the Python version
| does not matter, it's just whatever version is required to
| make the package work.
| godelski wrote:
| > not dependencies for your own Python projects
|
| I'm not doing that. Honestly I'm not sure how to do that
| and it sounds like a real pain. > the
| Python version does not matter
|
| This is incorrect. Go check what versions of Python brew
| has installed for you. It's definitely not your system
| version...
|
| It's not "what works" it is "what the maintainer
| specified". And according to the brew devs this is supposed
| to be /the latest version that works/. Which was my point.
| People don't update just on a Python change. That's not
| going to happen without automation. (I even suggested we be
| allowed to specify the minimum version and I was told it's
| maintainer's responsibilities). You can trivially find
| packages that can be used with newer versions of Python
| than their brew formulas specify.
| pm215 wrote:
| My experience was actually the opposite -- a package I
| used broke because somebody did an automated "bump the
| python version this package uses" change without noticing
| that upstream for the package hadn't yet made a release
| with the necessary changes to make it work with that
| python version, so it fell over on startup. (They were
| quick with reverting it when I reported the problem.)
| godelski wrote:
| That happens too. But that's normal bugs.
|
| For the issue I'm talking about you have to look. It's a
| non breaking bug. So unless you look you likely won't see
| the problem.
|
| That's two types of bugs: 1) Those that scream at you 2)
| Those that hide. We're talking about by later
| woodruffw wrote:
| I don't follow the argument here:
|
| * One of the main reasons Homebrew doesn't use the
| "system" Python is because Apple has repeatedly indicated
| that they want to remove it, and that integrators should
| not depend on it. This, plus per-package Python version
| requirements makes using a single system Python a non-
| starter.
|
| * The "bloat" you're noting in Homebrew around multiple
| Python interpreters is present in `uv` and `pyenv` as
| well: `uv` handles multiple interpreters transparently,
| so you may not even realize how many you have installed.
| I think this is a _good_ pattern: disk space is cheap
| relative to the timesink of connecting the right Python
| version to the right set of packages, which is why every
| distribution scheme (including both Homebrew and Debian)
| prefers to distribute multiple Python versions.
| godelski wrote:
| > because Apple has repeatedly indicated that they want
| to remove it
|
| That's not a reason to not use it. There's absolutely
| zero reason for me to have two copies of an exact same
| Python version (e.g 3.11.4). There is rarely reason to
| have a differing subversions (3.11.3 vs 3.11.4).
| > is present in `uv`
|
| Are you guessing or do you know? Try it out. Prove me
| wrong.
|
| I said they search for versions on your system and link
| if found. Seriously, look into it > disk
| space is cheap
|
| That's not correct. It's a thing you need to consider
| when you have to compromise but not an infinite resource.
| But there's something cheaper than storage: infrequently
| scanning the system!
|
| The problem is when everyone thinks this way then space
| is no longer cheap (especially with Apple!)
|
| Tragedy of the commons
|
| In fact it's a big reason I live in the terminal. Because
| even on a modern M2 air that bloat creeps in. My system
| is fast and snappy. I have plenty of storage. But this
| isn't true if I didn't. The creep still happens in these
| programs but their nature lessens the blows and the
| likelihood that people care about these things increases.
| woodruffw wrote:
| > That's not a reason to not use it.
|
| It is, in fact, an excellent reason not to use it.
| Homebrew runs on tens of millions of machines; we are
| absolutely not going to rely on things that we're told
| not to rely on unless absolutely necessary. Python is
| readily buildable and we _already_ need to build multiple
| versions for reasons aforementioned, so this condition
| does not apply.
|
| Also note, it's stronger than what I originally said:
| 10.15 doesn't ship with Python by default at all anymore.
| I only have it installed (at 3.9.6) because I also have
| XCode installed. Homebrew supports being used without
| XCode or the CLT, so that alone would be a hard blocker
| for system Python for us.
|
| > Are you guessing or do you know? Try it out. Prove me
| wrong.
|
| My `uv python list` shows that I have 3 uv-managed
| versions of Python installed, along with 5 pyenv versions
| and 2 Homebrew versions. I have more than most people
| because I test large matrices of Python versions at once,
| but I imagine a normal Python developer isn't too far
| off.
|
| You can test this for yourself with the same command. If
| you're developing more than one Python library or
| application at a time, I strongly suspect `uv` or `pyenv`
| is using more space for Python versions than Homebrew is.
| godelski wrote:
| > an excellent reason not to use it
|
| You're really missing my argument here.
| >> there's something cheaper than storage: infrequently
| scanning the system!
|
| The solution already exists If required
| python version does not exist, download.
|
| This is already being done. The missing part is the
| scanning of the system. I need to make this abundantly
| clear: You do not need to rely on Apple for this to be a
| solution. Furthermore, even if Apple completely removes
| python, making this change would still improve brew and
| reduce bloat. This is why I didn't care about that
| comment. Because it is inconsequential to what I'm
| suggesting. If they remove python you're in the exact
| same position as not having the right version of python.
| It is equivalent. I'm not sure why you're harping on
| this. > My `uv python list` shows
|
| You're again missing the point. It isn't about having
| different versions, hell I got 3.13, 3.12, 3.11, 3.10,
| 3.9, and 3.8 on my system. The problem is having
| redundant copies of the minor (or even patch) versions.
| When I installed `uv` I uninstalled brew, purged
| everything, and reinstalled. This is because when I'm
| creating a new venv it isn't actually `uv` that is
| installing a new python version, it is linking one that
| was installed by brew. When I was using Anaconda, conda
| didn't search for existing versions (and packages), it
| just installed its own. You might be thinking this isn't
| a problem with brew and a problem with conda, but that's
| passing the buck. Brew is making the same error that
| conda was and thinking brew is better and that the
| solution should be fixed by others is just idiotic. Its
| blaming those downstream for a problem that's being
| created. If a "crime" is a "crime" then it doesn't matter
| who does it.
|
| We're getting off topic now, since this is besides the
| point. But hey, here's a few things that can help look at
| the system and what's happening.
|
| On my system, brew installed 3.13, 3.12, and 3.11 (you
| can guess when I purged). For good measure, try this
| instead brew list | xargs -P8 -n1 sh -c
| 'brew cat "${0}" | grep "depends_on \"python@3." | sed -e
| "s/.*\(python@3\.[0-9]*\).*/\1/g"' 2> /dev/null | sort -u
|
| This will go through all your brew packages and find the
| python depends. My output shows 3.11 and 3.12.
| Interestingly, no python 3.13, though brew installed
| this. Interesting considering brew and brew-core don't
| have python code (according to github). Maybe something
| installed it and then I removed it. I'm unsure. But let's
| edit our command and check only those python@3.11
| instances. brew list | xargs -P8 -n1 sh
| -c 'brew cat "${0}" | grep "depends_on \"python@3.11" &>
| /dev/null && echo "${0}"' 2> /dev/null
|
| I checked the formulas on github, none of those even have
| python 3.11 anymore. These are cryptography, libxml2,
| numpy, py3parser, py3cairo, python-cryptography,
| pygobjects3, and python-packaging. With the exception of
| python-cryptography and python-packaging (no GitHub
| formula), the brew formula on GitHub depends on both 3.12
| and 3.13 for every one of these. There is no dep for
| 3.11! Did a `brew update` and `brew upgrade` and they're
| still 3.11. But hey, now the first brew list command
| reports 3.11, 3.12, and 3.13. Doing `brew info python-
| cryptography` there's a green checkmark on `python@3.12`
| and `python@3.13` (`python@3.11` is not shown), while
| `python-setuptools` has a red x despite the fact that I
| have setuptools installed in both 3.13 and 3.12 in
| different uv environments (it also isn't finding rust).
| So it certainly isn't finding packages and trying to
| reduce redundancy which is the big problem `uv` tries to
| solve in the first place.
| saint_yossarian wrote:
| https://mise.jdx.dev/ supports uv through its pipx backend,
| and is a very good package/tool manager in general.
| godelski wrote:
| Thanks! I'll check it out!
| alexykn wrote:
| love uv <3 I will look into integrating that. Have not
| decided if and how to implement my own packaging / source
| build dsl though and will probably open a git poll for that
| the coming days
| godelski wrote:
| Awesome! I look forward to see how this progresses! It'll
| be nice to have a package manager that supports true
| multithreading and is just overall a lot faster. There's a
| lot of things that are needed that brew simply just can't
| do.
|
| I haven't played around with this yet (will this weekend!)
| but I know brew is way too verbose and IO is a big
| slowdown. Probably doesn't matter because it is written in
| ruby. But it's an easy thing to miss and is quite common
| for people to not recognize this. Like when people use `tar
| xvf` instead of `tar xf`, there's a _very_ noticeable speed
| difference for many packages lol. (Sorry if I 'm preaching
| to the choir here. It's a pet peeve of mine given how
| common this is)
| AlphaSite wrote:
| Can you just shell out to homebrew for unsupported cases? I
| don't imagine the overhead of ruby will be that high compared
| to compiling the code.
| miki123211 wrote:
| > 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
|
| Last I checked (which was about a year ago), Homebrew had ~7000
| formulas (not including casks).
|
| I think it would be feasible to transcribe most of them to your
| format of choice with AI, run the build in a loop and ask the
| LLM to fix errors, and reserve manual intervention for the few
| cases that the LLM can't fix.
| alexykn wrote:
| Yeah, this would 100% be feasible. Great idea. It's during
| the week now so I don't have much time besides work.
|
| I'll probably open a Poll on git within the next couple days
| about what to do about a real from source packaging system
| with it's own dsl, maybe just yaml/toml or something a bit
| more powerful like lua with mlua. No matter the choice of
| packaging apporach I would like to keep the generated
| packages "bottle compliant" -> at least with the json api
| spec, since this also installs from there.
|
| There seems to be at least some in my project so even though
| I am very opinionated on a lot of things I don't think I
| should decide on that completely alone, especially given that
| this is the first time I play with packaging.
| alexykn wrote:
| on github xD
| 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
| hk1337 wrote:
| I don't want it there either. The install script is defines
| the install directory without anyway to override it. It sets
| it to /usr/local or /opt/homebrew depending on the result of
| uname command.
|
| I like it in ~/.brew where I have full permission to it and
| only my user.
| rgovostes wrote:
| As described on https://docs.brew.sh/Installation#untar-
| anywhere-unsupported:
|
| > Technically, you can just extract (or git clone) Homebrew
| wherever you want.
|
| However, Homebrew maintainers are dickish about essentially
| banning you from contributing to the project if your
| installation is nonstandard. They have a similarly
| discouraging warning if you are running a developer beta,
| which has turned me off of contributing fixes to broken
| formulas lest they reject them.
|
| > If you decide to use another prefix: don't open any
| issues, even if you think they are unrelated to your prefix
| choice. They will be closed without response.
| 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.
| meesles wrote:
| `brew ls --versions` + `brew list | xargs brew list`
|
| Everything you need is there...
| 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:
| Certainly, but I'm sure there's a more descriptive name
| than "cask"!
| chuckadams wrote:
| The nice thing about new terms is they don't have
| overlapping meanings with existing ones. And FFS why do
| people want to suck the joy and frivolity out of
| everything?
| p_ing wrote:
| A HIVE is the only nonsensical name in the registry;
| everything else is keys, subkeys, or values.
|
| https://learn.microsoft.com/en-
| us/windows/win32/sysinfo/stru...
|
| That said, the registry has been around for ~30 years and the
| terminology is well known to Windows users. It didn't build
| off of previously available terminology.
|
| Homebrew just made shit up on the spot based on the project's
| name to be internally consistent with itself.
|
| Microsoft has it's own fsckery of randomly named cute crap
| elsewhere, of course.
| 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.
| philsnow wrote:
| Love (lua thing for graphics / games) historically had this
| but the names were all sex-related (SECS, LUBE, COCK, AnAl,
| HUMP, Polygamy, Swingers, Quickie). None of the project names
| were metaphorically related to their functions.
|
| It's toned down lately and a ton of projects have been
| renamed, though not scrubbed, so the old names are still in
| the code and some documentation uses the old names. Also, you
| can't rewrite tens of thousands of forum posts from 2010 that
| use the older names that show up while searching for issues.
| 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.
| ks2048 wrote:
| I agreee with this, but is there a "standard" of terms? "repo"
| I understand to be a git repo, with all it entails. But,
| "package", "library", "module"? It seems like different
| languages have differenct usages.
| 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.)
| internetter wrote:
| Could you parallelize intelligently based on these
| heuristics? Like, say, whitelist GitHub and S3 for
| parallelizing
| SonOfLilit wrote:
| When I asked a few years ago, the brew maintainer said
| "parallelizing at this scale would hurt github, source: I
| work for github"
| IshKebab wrote:
| Definitely sounds like one of those "I don't want to do
| it because it's work, but I don't want to admit that so
| here's a spurious technical reason" excuses to me.
|
| If spikes at midnight etc are an issue just automatically
| disabled parallel downloads around midnight. Or only use
| them when running in a terminal. I really doubt it _is_
| an issue for GitHub though.
| woodruffw wrote:
| Can you think of _any_ more charitable reason than this?
| I think it beggars belief that Homebrew _isn't_
| interested in improving performance; it's something we
| talk about constantly and is one of our largest and most
| consistent user asks.
|
| (It's not just midnight, or terminals, as mentioned, not
| that either of these is really a "just". And it's not
| just GitHub, as mentioned.)
| SonOfLilit wrote:
| (In this subthread it is just github because we were
| discussing enabling parallelism for github only. The
| terminal proposal meant "keep it single thread for CI")
| woodruffw wrote:
| Okay. The problem is still present in the GH case,
| although to a lesser extent.
|
| These kinds of complications on a "same experience for
| everyone" flow are also nontrivial: single-threading on
| CI is hard to explain to users who see very fast local
| installs and slow CI installs - the latter costs them
| extra money! - and complicates the story with mirrors,
| download groups that include non-GH origins, etc.
|
| That's not to say it's impossible; as linked in another
| thread, it's something that's being actively worked on.
| But I think it should be understandable why "just
| parallelize it and you're wrong/stupid/lazy because you
| haven't already" is neither a contextualized or
| charitable response.
| IshKebab wrote:
| To be clear I think "it's a lot of work and we don't want
| to deal with the complexity" is a totally valid reason. I
| have that reason for not doing a ton of things.
|
| I just don't think "it shouldn't be done" is really the
| _true_ reason. It 's very tempting to say that though
| because it sounds like a stronger defense than "I don't
| want to". I think some people that do it don't even
| realise.
| 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.
| KolenCh wrote:
| I think you mean "the hell I got from the team".
|
| I wonder if anything changed substantially over the years to
| make you say that?
| saagarjha wrote:
| I feel like it's quite rude to deny to someone's lived
| experience and then ask what might have changed to make
| them feel that way.
| KolenCh wrote:
| To those who downvote, care to explain? Homebrew community
| is notorious in how they treat users on their GitHub Issues
| and I wonder why anyone is downvoting without showing how
| that situation have changed.
| chrisweekly wrote:
| > "it's very hard to RIIR"
|
| RIIR - "Rewrite It In Rust" (maybe obvious in context? sharing
| in case not)
| montag wrote:
| IWNO, thanks.
| OJFord wrote:
| I was not.. oware either, also thanks.
| j16sdiz wrote:
| it was not obvious, thanks
| fastball wrote:
| Yeah, to me the language (ruby) has nothing to do with the
| success of Homebrew, it is entirely about the DX around backend
| packaging. The main reason I switched from MacPorts to Homebrew
| back in the day is because when a new version of [insert
| software here] was released, I could expect the brew package to
| be updated within days. MacPorts always lagged significantly
| behind, and oftentimes didn't have certain packages at all.
| woodruffw wrote:
| I completely agree. I think Ruby has actually been a pretty
| great boon of a language choice because of the formula DSL,
| but that goes back to the DX point and not something
| fundamental to the language.
| mdaniel wrote:
| Merely for your consideration, Ruby is great if you live in
| that codebase all the time, but Ruby -- in general, not
| just Homebrew -- has indescribably bad discoverability. I
| mean that both in terms of "what can I write where my
| cursor is?" and its friend "where the hell did this symbol
| under my cursor come from?"
|
| I'm acutely aware someone's going to say LSP something or
| Rubymine something else but as for drive-by contributions,
| ... anyway, like I said, just for your consideration
| mdaniel wrote:
| As best I can tell, that's partially due to the size of the
| community, but also because Homebrew went out of their way to
| teach the system to fish via the 3(?) different kinds of
| "check for updates" built into the Formulae:
|
| - GitHub release sniffing
| https://github.com/Homebrew/homebrew-
| core/blob/b331b99b9f24f...
|
| - page scraping https://github.com/Homebrew/homebrew-
| core/blob/b331b99b9f24f... (and also per-content-type flavors
| json and presumably xml)
|
| - links to other formulae (IOW cascading updates):
| https://github.com/Homebrew/homebrew-
| core/blob/b331b99b9f24f...
|
| and then the $(brew livecheck) invocation which will do a
| subset, a curated list, or hypothetically all of them
|
| I can't imagine why MacPorts or our new Sapphire friend
| couldn't adopt a similar strategy
| fastball wrote:
| When Homebrew started (and when I switched) the community
| was significantly smaller than MacPorts. It is due to the
| system you mention (and the community that this MX in turn
| cultivated) that allowed brew to dominate the mac packaging
| market.
|
| Absolutely MacPorts and Sapphire can adopt the same
| strategy, but the point is that brew already has, so what
| exactly would the benefit be? e.g. if the language of
| choice is effectively meaningless, re-writing homebrew in
| Rust serves effectively no purpose. This is contrasted with
| systems and software where the performance or correctness
| is the most important feature, and therefore RIIR can be a
| big win.
|
| Said another way: Brew was not "re-write MacPorts in Ruby",
| it had much loftier goals which it then executed on
| effectively. Sapphire mostly seems to be "re-write Brew in
| Rust", without much beyond that. So the only real gain is a
| bit more performance out of the CLI.
| saagarjha wrote:
| MacPorts already supports "livechecks" which do the same
| thing. It's just that there are fewer people who are doing
| this regularly.
| 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.
| agos wrote:
| this kind of errors are quite common with Homebrew in my
| experience. if you did anything "wrong", then it's
| something really easy to do wrong which lots of other (me
| included) have done wrong at some point, and that the
| software should help to prevent
| frollogaston wrote:
| Digging through it more, it seems like Homebrew didn't
| play nice with anything else that used that dir. Maybe
| it's less of a problem now that it installs to
| /opt/homebrew, but I imagine there are still times
| Homebrew needs to place files in root-owned dirs or next
| to them.
|
| This issue is also brought up in the Github commit posted
| here: https://news.ycombinator.com/item?id=43766371 "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)."
| JimDabell wrote:
| My Macs aren't used by multiple _people_ but they are
| multi-user systems. At minimum I have work and personal
| accounts, often project-specific accounts too. Homebrew is
| really bad at this and I was hoping anything that came
| along to replace it would do better. All the similar tools
| like APT etc. can handle this, it's such a pain that
| Homebrew makes it difficult.
| frollogaston wrote:
| And it's multi-user in a way even if you only have one
| account, cause the other account is root, and some stuff
| besides Homebrew will install as root.
| 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
| kccqzy wrote:
| There are rolling distros on Linux that are remarkably stable.
| My current Linux distribution openSUSE Tumbleweed is one. And
| on macOS you already have an immutable system partition that
| provides a stable base to build on top of, so I fail to see the
| value proposition of a package manager on macOS that's
| deliberately slow.
| 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.
| jen20 wrote:
| Yeah, I thought I had edited my post to say it doesn't look
| to still be alive (apparently I did not!) - that's a shame,
| having diversity in this space is good.
| 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?
| Rodmine wrote:
| Obvious joke is obvious... but it seems the "motivation" is
| to write a project in rust.
| 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)? :)
| fastball wrote:
| The name of the project doesn't need to be the same as the CLI,
| e.g. Homebrew -> brew.
|
| This could be Sapphire -> sap
| 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)
| maartn wrote:
| Yeah, sure, bury UX tips in "also possible workarounds"
| 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.
| KingMob wrote:
| Funny, I gave up on nix-darwin recently after a year, and went
| back to homebrew.
|
| Trying to manage nix was more work than I wanted to do.
| 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.
| rewgs wrote:
| Really glad to see that someone has started on a Mac package
| manager written in Rust.
|
| A couple purely superficial suggestions (echoing some other
| comments here):
|
| - Lose the Brew terminology, especially if the name of the
| project isn't a synonym of "brew." - Change the name in general.
| "Sapphire" makes me think of "Ruby." IMO the obvious name is
| MacPac :p
| renecito wrote:
| so cool!, but can you invert a binary tree? /s
| vmsp wrote:
| Homebrew was kind of slow, at one point, but I find that it works
| pretty well these days. Still, this is pretty cool and
| competitions is always good.
|
| Interestingly, I always imagined that a would-be replacement
| would come written in Swift. I guess I was wrong.
| xyst wrote:
| Cool project. Definitely starring. But I'm sticking with nix to
| manage across systems.
|
| Yes a steep learning curve but once you have it set up then it's
| easy to sync across devices.
| microflash wrote:
| There's also `cart` : https://github.com/heywoodlh/cart
|
| I especially like their claim of being unprivileged. Very early
| stages just like Sapphire.
| TriangleEdge wrote:
| In my experience, rewriting software doesn't work. You should
| replace the components iteratively in Homebrew itself if you want
| your ideas to succeed. I doubt your software will see any major
| adoption just because you wrote it in some other language. The
| word Homebrew is culturally significant in hacker groups as well
| and sapphire is not.
| adamnemecek wrote:
| Yeah that's not possible.
| MelodyUwU wrote:
| still, nothing can replace macports for me, ever
| a-french-anon wrote:
| I use Macports on my work Macbook, but I'd love for Portage
| prefix to be fully functional on ARM Mac, personally. The tool
| interface is just so much better.
| snekcaseenjoyer wrote:
| Looks awesome. Thanks for your hard work, I will try this out at
| some point :)
| MarkMarine wrote:
| Why is parity with home brew the bar? Add something else great,
| like the ability to pin versions and not always install
| everything at head. Give me a reason to stop using home brew
| exabrial wrote:
| I used to donate to the Homebrew project and actually liked it,
| until it's enshitification a few years ago.
|
| * excessive superflurious animations? hell yeah
|
| * emojis everywhere? of course!
|
| * forced updates on by default
|
| * breaking updates? thanks your problem noob. Try to keep up.
|
| * versioning? lol, this isn't NASA
|
| * backwards compatibility? Lol. come on, we redesigned the
| standard, the right way, the 5th time this time.
|
| Its easy to criticize open source when you're not contributing,
| but thats why I sent my dollars over there, as I couldn't donate
| my time. Frustrating.
| smetannik wrote:
| One small note - it's quite easy to make a mistake typing
| "sapphire" command, especially if you have dyslexia.
|
| Is it possible to have more short command name?
| rbanffy wrote:
| I think the best replacement is still MacPorts.
___________________________________________________________________
(page generated 2025-04-23 23:01 UTC)