nixos-container: re-enable nixpkgs option
#98655
Conversation
erikarvstedt
force-pushed
the
fix-container-pkgs
branch
from
ffd0cae
to
37d7c8d
Compare
Since the introduction of option `containers.<name>.pkgs`, the option `nixpkgs` (including `nixpkgs.pkgs`, `nixpkgs.config`, ...) was always ignored in container configs. This option is now honored again if `pkgs == null`. The default behavior (including its performance benefits by re-using pkgs) is unchanged. Also, remove the redundant definition of `baseModules`, which is identical to the one in `eval-config.nix`.
erikarvstedt
force-pushed
the
fix-container-pkgs
branch
from
37d7c8d
to
3d730f6
Compare
| evalConfigArgs = optionalAttrs (config.pkgs != null) { | ||
| pkgs = confPkgs; | ||
| inherit (confPkgs) lib; | ||
| }; |
There was a problem hiding this comment.
We should probably write some code to warn users that when defining your own pkgs for a container, no overlays will apply.
There was a problem hiding this comment.
I think the extra description of pkgs is enough.
Maybe we should revert to the old behaviour, to avoid breaking existing configs. The only downside is the decreased performance.
Edit: I think reverting is the best way to go . All container configs using nixpkgs are broken since #85570.
| @@ -528,10 +529,12 @@ in | |||
|
|
|||
| pkgs = mkOption { | |||
| type = types.nullOr types.attrs; | |||
| default = null; | |||
| example = literalExample "pkgs"; | |||
| default = pkgs; | |||
There was a problem hiding this comment.
Any reason you changed the default here? Isn't null the better default as this means that by default, overlays in existing configs from 20.03 still apply?
There was a problem hiding this comment.
To quote myself:
The default behavior (including its performance benefits by re-using pkgs) is unchanged.
You may have misread this change, for the reason that the current version of nixos-containers.nix is a bit flawed:
The values null and pkgs for containers.pkgs are equivalent; the extra allowed value null is completely redundant. It is with this PR that null unlocks special behavior (namely container-configured pkgs).
erikarvstedt
force-pushed
the
fix-container-pkgs
branch
2 times, most recently
from
ef45593
to
199140b
Compare
erikarvstedt
force-pushed
the
fix-container-pkgs
branch
from
199140b
to
64ec840
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/20-09-unable-to-use-overlay-in-containers/10442/2 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/20-09-unable-to-use-overlay-in-containers/10442/3 |
|
I'm not too familiar with containers: I don't understand the original change in #85570, if you could already use |
|
@rnhmjoj, thanks for looking into this. This PR is now superseded by #106767. |
erikarvstedt
force-pushed
the
fix-container-pkgs
branch
2 times, most recently
from
aa98d64
to
64ec840
Compare
This PR is superseded by #106767.
Since the introduction (#85570) of option
containers.<name>.pkgs, the optionnixpkgs(includingnixpkgs.pkgs,nixpkgs.config, ...) was always ignored in container configs.This option is now honored again if
pkgs == null.The default behavior (including its performance benefits by re-using
pkgs) is unchanged.Edit: The fixup commit reverts to the default behavior of 20.03/20.09 to fix existing container configs broken by #85570.
Also, remove the redundant definition of
baseModules, which is identical to the one ineval-config.nix.Reproduce
The following config was broken before and is fixed by this PR:
Fixes #88621.
cc @adisbladis