Policy on checks/logic in stdenv.mkDerivation

[dezgeg]

According to #17886 (comment) and #25304 (comment), logic in mkDerivation seems discouraged on the basis of increased evaluation time. However, since 17.09 we seem to have grown at least these new ones:

nixpkgs/pkgs/stdenv/generic/make-derivation.nix

Lines 50 to 57 in 51179c6

	let
	supportedHardeningFlags = [ "fortify" "stackprotector" "pie" "pic" "strictoverflow" "format" "relro" "bindnow" ];
	# hardeningDisable additionally supports "all".
	erroneousHardeningFlags = lib.subtractLists supportedHardeningFlags (hardeningEnable ++ lib.remove "all" hardeningDisable);
	in if builtins.length erroneousHardeningFlags != 0
	then abort ("mkDerivation was called with unsupported hardening flags: " + lib.generators.toPretty {} {
	inherit erroneousHardeningFlags hardeningDisable hardeningEnable supportedHardeningFlags;
	})

and

nixpkgs/pkgs/stdenv/generic/make-derivation.nix

Lines 114 to 121 in 51179c6

	# This parameter is sometimes a string, sometimes null, and sometimes a list, yuck
	configureFlags = let inherit (lib) optional elem; in
	(/**/ if lib.isString configureFlags then [configureFlags]
	else if configureFlags == null then []
	else configureFlags)
	++ optional (elem "build" configurePlatforms) "--build=${stdenv.buildPlatform.config}"
	++ optional (elem "host" configurePlatforms) "--host=${stdenv.hostPlatform.config}"
	++ optional (elem "target" configurePlatforms) "--target=${stdenv.targetPlatform.config}";

I don't know if "bloat" in mkDerivation is still considered a problem or not, but if it is this probably deserves documenting somewhere and making sure that the policy is applied consistently.

[edolstra]

Yeah, it's better to do such checks in the builder (ideally in a separate setup hook).

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[abathur]

Closing since it sounds like Eelco answered the question, but I'm happy to reopen if you disagree.

(I guess the obvious objection is that this answer should be documented instead of just living in reviewers' heads and a GH comment. I just skimmed, but I don't see an obvious place for this in the manual. Maybe it could be a code comment in the file itself?)