[KingMob]

> What is the real reason then?

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.

[pxc]

The Homebrew package you linked is a Linux package. It doesn't build or run on macOS. It literally says 'Requires Linux' right there on the page.

[rekado]

Clearly we do not have a shared understanding of identity.

[KingMob]

We don't have a shared understanding of something, because I don't know what you're referring to by "identity" there.

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

[rekado]

Identity in this sense: https://en.wikipedia.org/wiki/Identity_(philosophy)

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.

[KingMob]

We're going around in circles now. I believe the Guix equivalent to something like nix-darwin would still be sufficiently guix-like (like a new language impl) to be worthwhile. You believe it wouldn't be guix, and iiuc, nothing short of your vision of guix would be guix, and since that can't be done from top-to-bottom on macOS, guix can't be done. I take it you don't view nix-darwin as nix?

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.