Skip to content

nixos/image/repart: Use own assertions / warnings.#406940

Merged
arianvp merged 2 commits intoNixOS:masterfrom
ElvishJerricco:push-yvkvxprpwqwx
May 15, 2025
Merged

nixos/image/repart: Use own assertions / warnings.#406940
arianvp merged 2 commits intoNixOS:masterfrom
ElvishJerricco:push-yvkvxprpwqwx

Conversation

@ElvishJerricco
Copy link
Copy Markdown
Contributor

This fixes some infinite recursion problems that are easy to trigger with the repart image builder. See commit message for details.

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:
  • 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/)
  • 25.05 Release Notes (or backporting 24.11 and 25.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.

Add a 👍 reaction to pull requests you find important.

It was easy to accidentally trigger infinite recursion if you depended
on `toplevel` in any way before. For instance, if you used
`CopyBlocks` with an image containing `toplevel`. This was because
`toplevel`'s assertion / warning logic has to be evaluated, but that
means evaluating `image.repart`'s assertions / warnings, which
requires evaluating the `repartConfig` attrsets to check for malformed
`Label`s. That causes the module system to type check *all*
`repartConfig` keys, even though most of them aren't used in the
assertions / warnings. So evaluating `system.build.image` evaluates
`repartConfig.CopyBlocks`, which evaluates `toplevel`, which evaluates
assertions / warnings, which evaluates `repartConfig.CopyBlocks` to
type check it. Infinite loop.

Even ignoring this recursion problem, it's still better for the repart
module to have its own assertions / warnings options. You don't have
to use `toplevel` in a repart image, so its assertions / warnings
would have been ignored in that case anyway. This way they're *always*
checked when you build an image.
@github-actions github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` 6.topic: lib The Nixpkgs function library labels May 14, 2025
@nix-owners nix-owners bot requested review from Profpatsch and hsjobeki May 14, 2025 05:38
@github-actions github-actions bot added 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels May 14, 2025
Copy link
Copy Markdown
Member

@arianvp arianvp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

Copy link
Copy Markdown
Member

@WilliButz WilliButz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't have
to use toplevel in a repart image, so its assertions / warnings
would have been ignored in that case anyway. This way they're always
checked when you build an image.

I agree, this is very nice!

@arianvp arianvp merged commit 871526b into NixOS:master May 15, 2025
20 of 21 checks passed
@roberth
Copy link
Copy Markdown
Member

roberth commented May 19, 2025

A similar solution was previously discussed. I believe this is worth looking into again, particularly now, as we can "avoid" adding a lib function, which is very coupled with the module.

cc @infinisil @hsjobeki


It feels unfortunate that we're doing this right before we have the means,

... to implement properly:

... but we have to see users' reality for what it is, and assertions.nix will stick around for another while anyway.

@arianvp
Copy link
Copy Markdown
Member

arianvp commented May 19, 2025

I'm fine with reverting this and cooking the library functions first. There is no time pressure here. At least not from my side.

@roberth
Copy link
Copy Markdown
Member

roberth commented May 27, 2025

Thanks.
Pushing for #207187 wasn't realistic because the release was about to happen, so we'll just do a deprecation cycle when we have a better alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: lib The Nixpkgs function library 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants