If you haven't tried it in the last year or two, then you might want to give it another try. Keep to some simple rules:
- Look for 'enable' toggles for particular software (for configuration.nix), rather than adding just the package. If it exists, use it; it wraps any extra configuration that's needed.
- Don't use nix-env. If you want a package installed temporarily, use nix-shell. Your system is probably single-user anyway, right? This way you can put configuration.nix in git.
- If you must use unpackaged software, then install and use steam-run. Despite the name, it's really just an Ubuntu-esque chroot. (...which duplicates the Steam runtime environment, yeah.)
Forcing people to build package recipes for everything they want to use is helpful, but not actually required. :)
There isn't a good story for doing declarative package management with user packages (nix-env isn't it), though there are a hundred hacks.
- It uses Scheme rather than Nix. Advantage Guix: Nix wasn't intended as a general-purpose language, and is only reluctantly letting itself be pushed therewards.
- It's philosophically pure. The package repository doesn't allow any kind of non-free software, whereas Nix allows it behind a global allow-unfree switch. Advantage: Nix?
- It's smaller. Perhaps as a result of the first two items, Guix has fewer developers and fewer packages.
Beyond that, they're basically the same design implemented two different ways. The Guix project is nice, and if NixOS wasn't around I'd use it. The communities have cordial relations, with a lot of overlap.
Guix uses the Nix daemon, which sets up the build environments, among other things. I would not call this "the primary Nix package management code".