However, I've run into a GUIX person or two who frame it as a technical issue because something like macOS lacks a completely verifiable build chain (i.e., needing to use XCode to bootstrap). This is a factual statement, but not the real reason why support for macos/windows is absent.
You can use Guix on macOS with https://superkamiguru.org/projects/msg.html, but it's probably not what people want when they ask for macOS support.
Unwillingness to compromise, as you might recall from our last conversation on the topic. This is your right, but framing it as a technical problem is incorrect.
> there is no glibc port for macOS
https://formulae.brew.sh/formula/glibc clearly proves otherwise. It just can't be built to your satisfaction with complete verifiability.
> Using XCode for everything
You don't have to use it for everything, that's a straw man. If Guix-darwin was willing to accept some impurity, you could probably use XCode just enough to bootstrap a glibc and compiler chain, and then dispense with it.
Having a completely verifiable toolchain is a laudable political goal, not a technical requirement.
nix-darwin's existence clearly shows there are no technical obstacles to an equivalent guix-darwin.
Believe me, I wanted to like Guix. I'd prefer a Lisp over the nix language, easily. But I'm losing respect for the project based on its messengers.
(If you're referring to "identity of who we're talking to", I can link you to our previous HN conversation, which is pretty similar to this one.)
Humans already have ways to build software on macos, so why bother doing it with something called "Guix" if the thing that we would necessarily --- and for technical reasons --- end up with bears little resemblance to Guix? If someone sees value in that, enough to warrant converting resources to realize this value, they are welcome to do just that.
Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
And yet, the nature of identity is always in flux. You are not made up of the same atoms as when you were an infant. Many lines of code in a software project change, and yet it remains the same, ship-of-Theseus style.
Guix's identity could encompass a guix-darwin side project and still remain guix. You think of it as a technical issue, but it's only your choice of what guix means that entails that view. Which comes right back around to my assertion that no macOS support is fundamentally a political choice of guix's devs, not a technical problem.
> end up with bears little resemblance to Guix
Based on my experience with nix-darwin, this seems like exaggeration, and I think most others would agree.
> Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
You are possibly the only person who is using "binary-blob-at-root" as equivalency criteria. Are you genuinely confused why macOS users aren't just using the Qemu Guix? Part of the appeal of nix/guix on mac is not having to pay the virtualization cost.
I wish they had a separate spinoff that just made sure their software can run on Windows and MacOS, something like exists for emacs, but I think that the challenges are pretty big as they appear to rely on Linux-only APIs?