nixos/misc/nixpkgs add setting nixpkgs.config.allowUnfreePackages = ["list" "of" "packages"] by dwt · Pull Request #396595 · NixOS/nixpkgs

dwt · 2025-04-06T16:39:47Z

Inspired by #197325 this adds a new option nixpkgs.allowUnfreePackages, which merges additively and can thus be defined in multiple modules close to where the unfree package is installed.

I would have liked ot name this option
nixpkgs.config.allowUnfreePackages, to define it closer to where the allowUnfree and allowUnfreePredicate options are defined, but I didn't see how this could be achived, given that nixpkgs.config is an attribute set or function instead of a module. I would welcome some guidance on how to do this.

I would also have liked to have an assertion that this setting should not be defined when nixpkgs.config.allowUnfreePredicate or nixpkgs.config.allowUnfree` is set, but I don't yet know how to do that. (And I would like to learn).

Closes #197325

Things done

Add a 👍 reaction to pull requests you find important.

nixos/modules/misc/nixpkgs.nix

roberth · 2025-04-06T17:02:28Z

nixos/modules/misc/nixpkgs.nix

To make this more scalable:

Suggested change

) (pkg: builtins.elem (lib.getName pkg) config.nixpkgs.allowUnfreePackages);

) (pkg: allowUnfreePackagesAsSet?${lib.getName pkg});

And then in a let binding outside of the pkg: function, something like

lib.genAttrs (_name: null) config.nixpkgs.allowUnfreePackages

Is there a way to get a feel for the performance tradeoffs of these kind of changes? In procedural languages, it is quite often faster to use lists for these kind of tests - for small lists of around 8 or less items, than produce a hash and add everything to it.

This of course hinges on the assumption that this is only called for the actual unfree packages that are in my closure, which should be usually be exactly as many as are in this list.

dwt · 2025-04-07T06:06:39Z

@roberth Thanks for the input, sorry to say that it will likely take me some time to react.

In the meantime: The eval fails with an error I'm not seeing locally:

  error:
       Failed assertions:
       - Your system configures nixpkgs with an externally created instance.
       `nixpkgs.config` options should be passed when creating the instance instead.

I would appreciate some guidance on how to reproduce / avoid this.

dwt · 2025-04-07T18:37:12Z

I would appreciate some guidance on how to reproduce / avoid this.

Looking at generic/check-meta.nix#126 it looks like the safest way to solve this would be to enhance that code to change the fallback function to look into nixpkgs.config.allowUnfreePackages by default, and not have a type for that thing at all, but just some configuration.

The whole thing is constructed in this strange way, which makes me think that there may be a rationale behind this? Perhaps something like that one can share the nixpkgs.config variable safely with a new instance of nixpkgs when importing it?

I have to admit that I don't really understand why this is built like this. :/

roberth · 2025-04-09T17:03:06Z

Failed assertions:
       - Your system configures nixpkgs with an externally created instance.
       `nixpkgs.config` options should be passed when creating the instance instead.

There's 2 ways to use Nixpkgs: standalone, where NixOS configures Nixpkgs, or you can use NixOS with an already configured Nixpkgs. Yours seems to be of the latter kind, based on the error message. You could either change it to ignore the pkgs you already have, or you could change the config where that pkgs is constructed.
To say anything with more certainty, I'd have to know more about how you NixOS config is created.

dwt · 2025-04-10T05:21:48Z

@roberth Not quite sure I get you, that error is from a check in a GitHub runner - not from my system. From reading the code it seems likely (though I didn't find anything definitive) that what I am doing in the code, that is setting something in nixpkgs.config from inside nixpkgs is unwanted? I don't quite grok the message and the code that generates it so the intent of that error message is not clear to me.

dwt · 2025-04-11T20:37:46Z

@roberth I think I found a better way to integrate this functionality. This involves a custom merge function on the nixpkgs.config type (which seems a bit messy), but the beauty is, that building the predicate now happens in check-meta.nix as a fallback if no predicate is defined. Therefore hopefully sidestepping the eval failure I this idea created before.

To me, there should probably be some sort of assertion to prevent you defining both a predicate and the list of package names, but at least it works, and doesn't complain in the nixpkgs checks, so this is hopefully a good start.

afh

👍 on the approach, please find minor comments

pkgs/top-level/config.nix

pkgs/stdenv/generic/check-meta.nix

dwt · 2025-05-08T11:01:30Z

Some more points for discussion / input that I gathered from reading the code, but am not sure I get correctly as I haven't found any documentation on this:

Is there a specific reason why the config attribute is not a normal nixpkgs module that merges via it's types, as they are defined in pkgs/top-level/config.nix? Something I was thinking of, is that this allows sharing the config attribute set between different nixpkgs instances (i.e. copying it over from your normal nixpkgs to nixpkgs-unstable or a local nixpkgs-dev)
This might also be the reason why it is a good idea to have a collection of strings in there, instead of jut collecting the packages directly. Is that the case? Is there some other reason?
Would it be better to assert that packages cannot be set together with the predicate? Or should the two be merged? Or should we allow that the predicate overrides the package list?

I guess there is more, but I would really like some input on these questions to know how to develop this further.

For this I would like to ping @roberth and perhaps @emilazy or some of the contributors who worked on this previously like @Stunkymonkey or @Mic92 or @reckenrode (at least if I interpret the history of these files correctly. Sorry if I don't).

As we don't have "NixOS/nixpkgs#396595" this is the best we can do currently.

dwt · 2025-12-28T15:39:22Z

@roberth I would also appreciate another review from you.

Majiir · 2026-01-03T03:35:55Z

This is working for me. 🎉 But the pull request title and commit descriptions still refer to nixpkgs.allowUnfreePackages, which confused me while I was switching over.

dwt · 2026-01-03T09:40:46Z

@Majiir am I missing something? What would you have expected the pull request title to be?

Majiir · 2026-01-03T16:32:55Z

The new option is nixpkgs.config.allowUnfreePackages, not nixpkgs.allowUnfreePackages.

…["list" "of "packages"] Inspired by NixOS#197325 this adds a new option nixpkgs.allowUnfreePackages, which merges additively and can thus be defined in multiple modules close to where the unfree package is installed. I would have liked ot name this option nixpkgs.config.allowUnfreePackages, to define it closer to where the allowUnfree and allowUnfreePredicate are defined, but I didn't see how this could be achived. I would welcome some guidance on how to do this.

nixos-discourse · 2026-01-11T14:02:17Z

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

https://discourse.nixos.org/t/prs-in-distress/3604/127

yuyuyureka

Diff looks good

nixos-discourse · 2026-01-27T10:49:26Z

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/6326

yuyuyureka · 2026-01-27T12:03:41Z

Thank you for your patience in waiting for the review and merge.

There are two followup tasks here:

Tree-wide, use the new option where it makes sense (tree-wide: use allowUnfreePackages where applicable #484367)
In pkgs/stdenv/generic/check-meta.nix you will find the code which suggests allowUnfreePredicates to the user to allow specific unfree packages when attempting to eval them. This should be changed to suggest allowUnfreePackages instead, although this requires a slight rework of remediate_allowlist / remediate_predicate.

jopejoe1 · 2026-02-13T10:19:03Z

Regarding of sharing the option type between nixos and pkgs made this pr for that #489889

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/` labels Apr 6, 2025

dwt mentioned this pull request Apr 6, 2025

Multiple allowUnfreePredicates should compose with or #197325

Closed

github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1 This PR causes 1 package to rebuild on Linux. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Apr 6, 2025

roberth reviewed Apr 6, 2025

View reviewed changes

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch from 33873b2 to 571ef97 Compare April 11, 2025 20:29

github-actions bot added the 6.topic: stdenv Standard environment label Apr 11, 2025

github-project-automation bot added this to Stdenv Apr 11, 2025

nix-owners bot requested review from Artturin, Ericson2314, RossComputerGuy, emilazy, philiptaron and reckenrode April 11, 2025 20:30

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch from 571ef97 to 76dca3e Compare April 11, 2025 20:44

dwt requested a review from roberth April 28, 2025 19:17

afh reviewed May 8, 2025

View reviewed changes

pkgs/top-level/config.nix Outdated Show resolved Hide resolved

pkgs/stdenv/generic/check-meta.nix Outdated Show resolved Hide resolved

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch from 76dca3e to 5ffc7a4 Compare May 8, 2025 11:01

eclairevoyant mentioned this pull request Dec 7, 2025

nixpkgs.config option having unintuitive merging semantic #468647

Open

Very-Blank added a commit to Very-Blank/Nixos that referenced this pull request Dec 10, 2025

fix: Make an option for unfree packages.

5766261

As we don't have "NixOS/nixpkgs#396595" this is the best we can do currently.

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch from c7c7599 to 308b135 Compare December 28, 2025 14:44

dwt requested review from afh and yuyuyureka December 28, 2025 14:49

nixpkgs-ci bot requested a review from adisbladis December 28, 2025 14:49

nixpkgs-ci bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Dec 28, 2025

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch 2 times, most recently from f30bf12 to 01a69f0 Compare January 1, 2026 16:20

dwt changed the title ~~nixos/misc/nixpkgs add setting nixpkgs.allowUnfreePackages = ["list" "of" "packages"]~~ nixos/misc/nixpkgs add setting nixpkgs.config.allowUnfreePackages = ["list" "of" "packages"] Jan 3, 2026

dwt added 2 commits January 3, 2026 20:40

nixos/misc/nixpkgs: add tests for nixpkgs.config.allowUnfreePackages

b9cccbb

dwt force-pushed the nixpkgs-config-allowUnfreePackages branch from 01a69f0 to b9cccbb Compare January 3, 2026 19:40

yuyuyureka approved these changes Jan 25, 2026

View reviewed changes

nixpkgs-ci bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Jan 25, 2026

yuyuyureka added this pull request to the merge queue Jan 27, 2026

Merged via the queue into NixOS:master with commit 918178a Jan 27, 2026
32 checks passed

github-project-automation bot moved this to Done in Stdenv Jan 27, 2026

dwt deleted the nixpkgs-config-allowUnfreePackages branch January 29, 2026 08:37

dwt mentioned this pull request Feb 2, 2026

nixos/misc/nixpkgs: add documentation for nixpkgs.config.allowUnfreePackages #485365

Open

13 tasks

lazulyra mentioned this pull request Feb 20, 2026

bug: nixpkgs.config.allowUnfreePackages not combining between functions nix-community/home-manager#8775

Closed

2 tasks

	) (pkg: builtins.elem (lib.getName pkg) config.nixpkgs.allowUnfreePackages);
	) (pkg: allowUnfreePackagesAsSet?${lib.getName pkg});

Uh oh!

Conversation

dwt commented Apr 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Things done

Uh oh!

Uh oh!

roberth Apr 6, 2025

Choose a reason for hiding this comment

Uh oh!

dwt Apr 7, 2025

Choose a reason for hiding this comment

Uh oh!

dwt commented Apr 7, 2025

Uh oh!

dwt commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roberth commented Apr 9, 2025

Uh oh!

dwt commented Apr 10, 2025

Uh oh!

dwt commented Apr 11, 2025

Uh oh!

afh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

dwt commented May 8, 2025

Uh oh!

dwt commented Dec 28, 2025

Uh oh!

Majiir commented Jan 3, 2026

Uh oh!

dwt commented Jan 3, 2026

Uh oh!

Majiir commented Jan 3, 2026

Uh oh!

nixos-discourse commented Jan 11, 2026

Uh oh!

yuyuyureka left a comment

Choose a reason for hiding this comment

Uh oh!

nixos-discourse commented Jan 27, 2026

Uh oh!

Uh oh!

yuyuyureka commented Jan 27, 2026

Uh oh!

jopejoe1 commented Feb 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

dwt commented Apr 6, 2025 •

edited

Loading

dwt commented Apr 7, 2025 •

edited

Loading