Live data from Hacker News

Sapphire: Rust based package manager for macOS

github.com

291–300 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#291
post #127

Earlier quoted context omitted.

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.

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.

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.

Re: Sapphire: Rust based package manager for macOS

#292
post #27

Earlier quoted context omitted.

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.

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

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

Re: Sapphire: Rust based package manager for macOS

#293
post #26

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 A…

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 se…

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

Re: Sapphire: Rust based package manager for macOS

#294

Earlier quoted context omitted.

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 se…

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

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)

Re: Sapphire: Rust based package manager for macOS

#295

Earlier quoted context omitted.

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 `p…

> 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…

> 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.

Re: Sapphire: Rust based package manager for macOS

#296
post #133

Earlier quoted context omitted.

The thing you want then is `fink`, which literally uses dpkg and apt.

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.

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.

Re: Sapphire: Rust based package manager for macOS

#297
post #26

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 A…

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/

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

Re: Sapphire: Rust based package manager for macOS

#298

Earlier quoted context omitted.

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 wel…

> 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?

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.

Re: Sapphire: Rust based package manager for macOS

#299

Earlier quoted context omitted.

> 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?

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…

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.

Re: Sapphire: Rust based package manager for macOS

#300

Earlier quoted context omitted.

> 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…

> 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 origi…

  > 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.
Post reply on HN