Earlier quoted context omitted.
IWNO, thanks.
I was not.. oware either, also thanks.
it was not obvious, thanks
Sapphire: Rust based package manager for macOS
231–240 of 311 posts
Re: Sapphire: Rust based package manager for macOS
#232Earlier quoted context omitted.
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.
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?
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.
Re: Sapphire: Rust based package manager for macOS
#233Earlier quoted context omitted.
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…
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…
MacPorts already supports "livechecks" which do the same thing. It's just that there are fewer people who are doing this regularly.
Re: Sapphire: Rust based package manager for macOS
#234Earlier quoted context omitted.
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.
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
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?
Re: Sapphire: Rust based package manager for macOS
#235Earlier quoted context omitted.
For the last 5 years (since Apple Silicon was released), Homebrew has installed to /opt/homebrew by default.
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.
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.
Re: Sapphire: Rust based package manager for macOS
#236I 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…
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.
> 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.
Re: Sapphire: Rust based package manager for macOS
#237Hey, 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…
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.
Re: Sapphire: Rust based package manager for macOS
#238Earlier quoted context omitted.
> 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.
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.
> 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.
Re: Sapphire: Rust based package manager for macOS
#239Earlier quoted context omitted.
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…
P2P protocols like BitTorrent are made for this kind of problem.
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.
Re: Sapphire: Rust based package manager for macOS
#240Earlier quoted context omitted.
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
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 majo…
> Is this your argument for a major rewrite?
A major rewrite in Rust.