From 69694ecde6ff57cb67d14e32210ae35d43466b3a Mon Sep 17 00:00:00 2001 From: Marien Zwart Date: Sun, 24 Mar 2024 15:38:29 +1100 Subject: [PATCH] Make pin requirement for generated builds explicit We were already setting `commit` to `p.pin` unconditionally, so the requirement is not new. Add an assert because this can be triggered from a user packages.el. --- package.nix | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/package.nix b/package.nix index 03b8ae9..d8ab898 100644 --- a/package.nix +++ b/package.nix @@ -123,6 +123,19 @@ let # building our own package. assert lib.assertMsg (!(p ? recipe.pre-build)) "${name}: pre-build not supported"; assert lib.assertMsg (!(p ? recipe.build)) "${name}: build not supported"; + # TODO: lift "pin" requirement, if that turns out to be + # necessary or at least desirable. Requires figuring out why + # melpa2nix requires `commit`. Not a priority because if it's + # not in epkgs we'd need a recipe passed in, and it's uncommon + # for Doom to pass in a recipe without pinning. + # + # Doom does currently have unpinned packages with an explicit + # recipe, but they're in epkgs (popon and flymake-popon) so it + # should be ok. Users might do this to pull in a custom package + # they don't care about pinning, though: we may want to support + # that. + assert lib.assertMsg (p ? pin) + "${name}: not in epkgs and not pinned. This is not yet supported."; # epkgs.*Build helpers take an attrset, they do not support # mkDerivation's fixed-point evaluation (`finalAttrs`). # If they did, the buildInputs stuff should use finalAttrs.src.