pkgsUnfree: init

[tomberek]

Adds a pkgsUnfree (similar to pkgsCuda, pkgsMusl, etc) variant to allow easier access to this config variant.

Things done

Created new package set variant.

[SomeoneSerge]

@tomberek wdyt about framing this in the "Builder" terms? https://github.com/NixOS/nixpkgs/pull/437723/files#r2361011957

[tomberek]

@tomberek wdyt about framing this in the "Builder" terms? https://github.com/NixOS/nixpkgs/pull/437723/files#r2361011957

That would be technically better, but pretty bad user interface and likely cause more confusion in most cases. I've played with that variation of that pattern for some things (eg: withPython3Packages.requests.click.numpy which was nice for small scale things). The fully generic approach needs just as much expertise/knowledge and typing and complexity as the explicit configuration options we have. I see the builder approach as a concession to UX for the 98% of cases to be easy.

[SomeoneSerge]

I fully agree, but that's also how I see pkgsUnfree. We had made an exception for pkgs{Cuda,Rocm}, which for me was justified because we currently have in-tree users like torchWithCuda, which need to refer to pkgsCuda from pkgs. Even those hopefully only temporarily. Even pkgsCross is somewhat questionable, and not strictly necessary. Should we start removing things instead?..

…

On 19 September 2025 15:39:07 UTC, tomberek ***@***.***> wrote: tomberek left a comment (NixOS/nixpkgs#435082) > @tomberek wdyt about framing this in the "Builder" terms? https://github.com/NixOS/nixpkgs/pull/437723/files#r2361011957 That would be technically better, but pretty bad user interface and likely cause more confusion in most cases. I've played with that variation of that pattern for some things (eg: withPython3Packages.requests.click.numpy which was nice for small scale things). The fully generic approach needs just as much expertise/knowledge and typing and complexity as the explicit configuration options we have. I see the builder approach as a concession to UX for the 98% of cases to be easy.

[tomberek]

I can see something like moving them so that they are grouped somewhere. aliases.pkgsCuda, or withConfig.allowUnfree.terraform. Right now the top-level has several categories of things, packages, package sets, libs, "config modifiers", functions, and so on. I can see there being an effort to group this stuff by type or function. Flakes might have a part to play here.

These would all be interesting to address across all of Nixpkgs as an architectural project. But in the meantime, I think it would greatly help UX to include pkgsUnfree. In most cases people will have to type it and it will be made explicit somewhere that they are opting in. Eg: environment.systemPackages = [ curl pkgsUnfree.terraform ];

[SomeoneSerge]

it will be made explicit somewhere that they are opting in

Unless pkgs.foo, unaware of conventions, consumes pkgsUnfree.bar as a dependency.

greatly help the UX

The Flakes UX. The current Nix UX in Nixpkgs is fairly good in comparison, despite the lack of decent CLI tools. I'm not exactly opposed to handling the rough edges for flakes too (or at least, "maintainer hat" on, I ought not be), but I'd strongly prefer that we find a path where each step makes sense regardless of flakes. I'm going to take some time to reflect whether I'm being irrational, and rejoin the discussion.

…

On 19 September 2025 15:57:39 UTC, tomberek ***@***.***> wrote: tomberek left a comment (NixOS/nixpkgs#435082) I can see something like moving them so that they are grouped somewhere. aliases.pkgsCuda, or withConfig.allowUnfree.terraform. Right now the top-level has several categories of things, packages, package sets, libs, "config modifiers", functions, and so on. I can see there being an effort to group this stuff by type or function. Flakes might have a part to play here. These would all be interesting to address across all of Nixpkgs as an architectural project. But in the meantime, I think it would greatly help UX to include pkgsUnfree. In most cases people will have to type it and it will be made explicit somewhere that they are opting in. Eg: `environment.systemPackages = [ curl pkgsUnfree.terraform ];`

[wolfgangwalther]

This adds a new package set as a variant purely for "better UX". See my comment in #400351 (comment) on why I think that this is entirely the wrong idea.

We should not be adding new variants - the whole idea of moving this into variants was to eventually get rid of them.

This specific case is just a simple config option. There is literally no useful information encoded (compared to e.g. pkgsStatic or pkgsExtraHardening). Just flip the config switch and you get the same result. Most importantly this is a config option that doesn't even change the whole package set.

This means that a lot of pkgsUnfree and pkgs are actually the same thing. This is not what package sets are about.

Personally, I think this should be closed, because the idea is just wrong.

[tomberek]

@wolfgangwalther I do agree that from a strict perspective this sort of thing is somewhat out of place. Just like lib/pkgsUnfree/pkgsStatic/pkgsCUDA/pkgsi686Linux/config/__splicedPackages/callPackage/etc all being in the top-level isn't quite right. The reality is that we do have them. I'd be happy to have all of these things more organized (i believe this was the intention of the "packages" top-level in flakes, to separate this stuff) and move all of them into whatever place they should be in. Having another one doesn't make that job much easier/harder at this point.

Until then, this provides a marked improvement and UX over the current state. This isn't a flakes/non-flakes issue. Either way you would have to either go write Nix import+configuration statements somewhere, or rely upon impure eval's action-at-a-distance with env vars or files.

Free software is our priority, but we also support our users' needs to use non-free software, when practical.

It comes down to a tradeoff in usability. I would never suggest we should turn on non-free by default - we should prioritize free software - but this is an opt-in mechanism that makes sense to me. This is an annoyance that comes up often as beginners try to use some software; this is part of our "learning cliff" that makes it much harder to use the overall system, especially when they are still learning. Considering that we have other similar non-compliant/lazy/redundant package sets, how often this comes up, and how much it would improve the UX, I think it would be a good addition that would be quite practical.

[alyssais]

I'm uneasy about doing anything that makes interacting with allowUnfree (as opposed to allowUnfreePredicate) easier to use. allowUnfree is pretty dangerous, because it means you have no insight into which licenses apply to the software you use, and even if you think you've checked them, they could have changed since you last looked. (For free software this isn't so much of a problem because there's a maximal set of acceptable restrictions, so as long as you're compliant with that the individual licenses don't matter so much.)

[wolfgangwalther]

Considering that we have other similar non-compliant/lazy/redundant package sets

That's the point - we don't. We don't have any similarly simple other package sets. every other package set in stage.nix or variants.nix has at least a little bit of logic or composition. The proposal here adds another layer - it's essentially just an alias for a single thing. That's a meaningful difference. You need to know about exactly the same kind of things to use either config.allowUnfree directly or to use pkgsUnfree.

[SomeoneSerge]

That's the point - we don't.

👍🏿 I'll reiterate one more time, that pkgsCuda is (1) not a counter-example (has in-tree consumers), and is (2) a compromise (purpose being to remove torchWithCuda &al) #437723 (comment) #435082 (comment)

anything that makes interacting with allowUnfree (as opposed to allowUnfreePredicate)

👍🏿 and, one more time, we have no tool that can "prove the closure is free", unless we simply never import nixpkgs with allowUnfree #437723 (comment) #435082 (comment)

[wolfgangwalther]

and, one more time, we have no tool that can "prove the closure is free", unless we simply never import nixpkgs with allowUnfree

Thank you for clarifying that once more - I had not understood the full consequences of this change before.

With this change:

• Unfree packages are available as variants, without a config option blocking them.
• Since we don't prevent use of variants in Nixpkgs, yet, we must very much expect that somebody merges a reference to pkgsUnfree into nixpkgs.
• Once there is a reference, hydra will build this unfree package.
• Once hydra builds it, this package will be distributed by the binary cache.

This means that this change is entirely unacceptable, because it risks us distributing packages, that we are not allowed to.

This is a definitive, legal blocker, without any room for negotiation, I'm afraid. For this reason, I am closing this PR.

[alyssais]

• Since we don't prevent use of variants in Nixpkgs, yet

Why don't we prevent the use of variants in Nixpkgs? Wasn't that the whole point of adding variants?

[SomeoneSerge]

Why don't we prevent the use of variants in Nixpkgs? Wasn't that the whole point of adding variants?

At least one common place to refer to variants is passthru.tests, with the intent of making CIs "aware" of, well, the variants. Means we'd have to find a better place for them

[alyssais]

I thought we specifically excluded everything that was already used in Nixpkgs from being moved to variants so that we could disable variant use in Nixpkgs. That's why e.g. pkgsStatic is still in stage.nix.

[wolfgangwalther]

My understanding is that, we still don't have variants disabled by default. It is the goal, yes, but it doesn't happen, yet, AFAIR.