So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base.
That's if you want the development environment.
On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker).
Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though.
Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is.
What's your use case?
x86_64-linux
aarch64-linux
i686-linux
x86_64-darwin
aarch64-darwin
Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer). - x86_64-linux
- i686-linux
- aarch64-linux
- powerpc64le-linux
- i586-gnuI just wanna note here that the hesitation to invest in macOS support in the Guix development community is technical as well as ideological. macOS is a difficult platform to support for third-party package managers, and developer interest in macOS support is a difficulty within the Nix community, too. There's a lot of breakage on major macOS upgrades as well as some fundamental portability and hermeticity problems on the platform.
That said, (as an outsider) I think it would be awesome if Guix ran on macOS, just like it's ultimately a good thing for the world and for GNU that Emacs runs pretty well on macOS.
It'd certainly make for a good blog post here. :)
It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
I'm aware Nix is closely integrated with SystemD, so availability on BSD will probably never happen (though perhaps you could use the Darwin code as a starting point?), but I'd be curious to know what in particular limits Guix from being ported.
The parent poster was probably conflating NixOS and Nix. NixOS is a way of using nixpkgs to build/configure and install/upgrade an operating system based on Linux and systemd. But you are not obligated to use systemd just because you're using nixpkgs.
NixOS uses sytemd for essentially the same reason other Linux distributions do: most user environments are now built with the assumption that systemd underlies them if Linux does as well. In principle you could fork nixpkgs and make all the necessary changes to remove the systemd assumption - managing a NixOS system and hacking on nixpkgs are basically the same skillset so it's not like managing an Ubuntu system where you would have to become familiar with how Ubuntu gets built. With nixos, the command is the same whether you're building an entirely new distribution based on a custom fork or whether you're just downloading builds of the latest security upgrades. Aside from the actual energy it takes to maintain a second system manager, you would only have to wait for the builds to complete rather than learning how to build everything. But so far no-one who has tried that has got enough traction - the cost-benefit just isn't there. Honestly, I think this is part of the reason people are offended by NixOS in particular using systemd: it feels like it should be possible for you to remove the systemd dependency, but you haven't done it.
Guix' packages include glibc in their dependency chain, so unless you can use glibc on BSD, there is your technical reason. For example GNU Hurd is supported in addition to Linux.