The value of Guix on macOS is that your users can use the same project definitions on macOS and Linux. I don't personally care about the "from-source bootstrap" all that much, I want tooling that I can use to express my system's configuration as code and nix does this just fine on macOS.
As far as the ideological reasons goes, last time I looked for this, someone on a mailing list asked how you'd go about porting guix to macOS and some core team member answered they had no interest in supporting a non-FOSS system.
Guix has recently landed support for building Guix System containers on top of WSL2. Emacs (another GNU package) also runs just fine on Windows.
This is not about supporting a non-free system; I bet some nuance was left behind on the way from writing that mailing list post to the comment I'm responding to. Building packages for macOS would require an entirely different underpinning --- or cheating but cutting the package graph and grafting it on top of the huge proprietary blob that is the macOS development environment. It would also require that we buy macOS licenses and operate macOS build farm nodes to build binaries.
And for what? The resulting packages would in no way be equivalent to their GNU+Linux counterparts. The "same project definitions" would not describe the same thing at all.
Comments
The value of Guix on macOS is that your users can use the same project definitions on macOS and Linux. I don't personally care about the "from-source bootstrap" all that much, I want tooling that I can use to express my system's configuration as code and nix does this just fine on macOS.
As far as the ideological reasons goes, last time I looked for this, someone on a mailing list asked how you'd go about porting guix to macOS and some core team member answered they had no interest in supporting a non-FOSS system.
Guix has recently landed support for building Guix System containers on top of WSL2. Emacs (another GNU package) also runs just fine on Windows.
This is not about supporting a non-free system; I bet some nuance was left behind on the way from writing that mailing list post to the comment I'm responding to. Building packages for macOS would require an entirely different underpinning --- or cheating but cutting the package graph and grafting it on top of the huge proprietary blob that is the macOS development environment. It would also require that we buy macOS licenses and operate macOS build farm nodes to build binaries.
And for what? The resulting packages would in no way be equivalent to their GNU+Linux counterparts. The "same project definitions" would not describe the same thing at all.