nixos/guix: init

[foo-dogsquared]

Description of changes

Now that #246975 is merged, at least why not make a service module for it. While some parts of the integration test is rendered redundant once the package enables checking (e.g., doCheck = true), I guess it's better than nothing.

cc @cafkafk

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[foo-dogsquared]

There are still some setups I have to figure out so it's in draft for now.

[cafkafk]

Ohh nice work, can't wait to try this out!

Maybe since you've done most of the work on guix you'd want to add yourself to the maintainers on the guix package as well?

[h7x4]

Note that there is also #264323. Maybe we could try to combine the efforts somehow? @viperML

[foo-dogsquared]

Maybe since you've done most of the work on guix you'd want to add yourself to the maintainers on the guix package as well?

Sure. That's fine by me.

Note that there is also #264323. Maybe we could try to combine the efforts somehow?

I'm open for ideas. (I find it amusing both PRs are drafted just within an hour)

[viperML]

Well my draft intended to open the discussion for the options, but it seems you already have the module ready.

[foo-dogsquared]

Well my draft intended to open the discussion for the options, but it seems you already have the module ready.

I only upstreamed the module from my Guix overlay and haven't updated or gave the module options a second look before this PR so there's still room for discussion.

[foo-dogsquared]

A few test setups later and it is done. Should be ready for review.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/2857

[SuperSandro2000]

Please read through the descriptions and make sure they are written in a style suitable for a manual.
Also please check that the comments explain the reason something is done and don't just elaborately describe the line below with little extra information.

[viperML]

• The nix-daemon.nix uses unitConfig.RequiresMountsFor = "/nix/store"; , should we do the same for /gnu/store ?

• And more of a general guix usage question, how are channels handled? The package already comes with some channels bundled?

[foo-dogsquared]

Please read through the descriptions and make sure they are written in a style suitable for a manual. Also please check that the comments explain the reason something is done and don't just elaborately describe the line below with little extra information.

Yeah, I neglected checking for the documentation on this one. My bad.

Will keep that in mind for future modules.

[foo-dogsquared]

• The nix-daemon.nix uses unitConfig.RequiresMountsFor = "/nix/store"; , should we do the same for /gnu/store ?

Good point. Will update the unit with those.

• And more of a general guix usage question, how are channels handled? The package already comes with some channels bundled?

If you meant managing custom Guix channels, this module does not handle Guix channels. You should be able to handle them as described in the manual. As for the package, it doesn't bundle any channels.

[hpfr]

Since this is a new module (and some new options for the Guix package that appear to match the previous baked-in values), could this be backported to 23.11? I recently started using your overlay repo (thanks!) and just noticed this PR that barely missed the release (and #246975 did make it). I was planning to switch to stable NixOS now that I can try moving my home environment to Guix.

[github-actions]

Backport failed for release-23.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-23.11
git worktree add -d .worktree/backport-264331-to-release-23.11 origin/release-23.11
cd .worktree/backport-264331-to-release-23.11
git switch --create backport-264331-to-release-23.11
git cherry-pick -x df46b418951994499f8b6c4cc12db65f807ea50f 092aaf841806e8a5fcdfea566bbaae2e25cea069 ad277ea47e17e3073ba61af07284d1dff8d1601e

[foo-dogsquared]

This has been backported to 23.11 (#272632). Now, it's a matter of waiting for it to land in nixos-23.11 branch (or whatever stable branch you're using).

---

Also I didn't know you can backport module additions. Nice.

[wegank]

Yes, new modules are backwards-compatible changes.

Meanwhile, this makes the change in the 24.05 release note obsolete.

[jian-lin]

Meanwhile, this makes the change in the 24.05 release note obsolete.

Could you elaborate the meaning of this and what action should be taken for

nixpkgs/nixos/doc/manual/release-notes/rl-2405.section.md

Line 17 in 55ca793

- [Guix](https://guix.gnu.org), a functional package manager inspired by Nix. Available as [services.guix](#opt-services.guix.enable).

.

[wegank]

I'd like to drop this line and, if possible, move it to the 23.11 release note.