-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixpkgs config inside machine definitions is ignored #34
Comments
You're absolutely right. This is not the first time I've looked into this issue, and it probably won't be the last. Most recent time we discussed it was at the release of NixOS 18.09, where we wanted to update the package set of only a subset of hosts in a network/group. At that time, I dropped it while well progressed into vendoring of eval-config.nix. At that time, I didn't think it was worth maintaining our own copy of part of the module system, just to get this to work. But.. Perhaps we should look into it again, and maybe we might even be able to upstream changes to eval-config if they are generic enough. |
@Shados let
p = import <nixpkgs> {};
p' = import <nixpkgs> { overlays = [
(self: super: {
pam_mount = super.pam_mount.overrideAttrs(oldAttrs: {
name = "pam_mount overidden by overlay";
});
})
];
};
common = { config, pkgs, ... }: {
system.activationScripts.testingOverlays = ''
echo "${builtins.trace pkgs.pam_mount.name "nak"}"
'';
fileSystems."/" = { label = "root"; fsType = "ext4"; };
boot.loader.grub.device = "/dev/sda";
};
in
{
network = {
pkgs = p;
description = "Example overlay/override failure";
};
"example.com" = { config, lib, pkgs, ...}: {
imports = [ common ];
nixpkgs.pkgs = p;
};
"example-withoverlays.com" = { config, lib, pkgs, ...}: {
imports = [ common ];
nixpkgs.pkgs = p';
};
} but for some reason (which I haven't investigated yet), still neither of UPDATE: I investigated further, and of course {
nixpkgs.pkgs = mkDefault (import (toString pkgs.path) {
inherit (config.nixpkgs) config overlays localSystem crossSystem;
});
} Have a look here: a869363 .. Perhaps test to see if this would work for you? |
mkForced. Instead, mkDefault the nixpkgs module to network.pkgs. This will make it overridable in deployment files. fixes #34
That works :). Of course, it would be nice to do something like: {
nixpkgs.pkgs = mkDefault (import (toString pkgs.path) {
inherit (config.nixpkgs) localSystem crossSystem;
config = pkgs.lib.recursiveUpdate pkgs.config config.nixpkgs.config;
overlays = pkgs.config.overlaysApplied ++ config.nixpkgs.overlays;
});
} So that you could merge machine-specific nixpkgs changes on top of the network-wide ones, but nixpkgs doesn't appear to actually keep an attribute listing the overlays used to build it. I think this would require only a trivial change to Edit: |
Well, adding such an attribute to the I also took a look into what could be done without changes to upstream nixpkgs, this is what I came up with: {
nixpkgs.pkgs = mkDefault (pkgs.appendOverlays (
pkgs.lib.optional
(config.nixpkgs.config ? packageOverrides)
(self: super: config.nixpkgs.config.packageOverrides super)
++ config.nixpkgs.overlays));
} But it has some differences compared to re-importing nixpkgs and passing in a merged overlays and config:
|
@Shados Yeah.. I tried to make it simple and transparent by not merging anything. In my example, you could deliberately decide that the network pkgs is for bootstrapping only; i.e. overlays and other package args are ignored by design. You'd then have to set That said; I agree that it would still be more ergonomic and beautiful to get the merging to work. :-) Let me try to play around with the snippets you posted and test with our setup. Thanks so far! I'll get back to you in the beginning of next week. |
Sounds good. Have a nice weekend :). |
@Shados I promised to get back to you in the beginning of this week. That... didn't happen, sorry :). I actually tried to reach you on IRC but nevermind. Basically; I'm good with the snippet you proposed, except |
All good, I did get a message from you on IRC, but not I think your initial one. And yeah, it looks like |
What's the current status of this? And now that 19.03 is stable, perhaps it can be reevaluated? :) |
Another failure mode: I have a machine definition in which I use nonfree packages, so I put I'd also like to have a cross-built buildOnly node in my deployment using |
I have a similar problem, which is blocking me from switching to morph. My “fleet” is made up of machines with different architectures, which I can achieve using NixOps with:
This option ofc unfortunately gets ignored by morph, causing the deployment to fail. |
Problem
Here's an example deployment file to demonstrate what I mean:
If you
morph build
that, you'll get trace output oftrace: pam_mount-2.16
or similar, rather thantrace: pam_mount overridden by overlay
as you would if you were building the same NixOS configuration any other way.Cause
Morph passes pkgs from the network to the machine definitions, which is nice in terms of pinning nixpkgs versions and sharing nixpkgs config between machines, but problematic because nixpkgs' eval-config.nix will set the
pkgs
module argument viamkForce
ifpkgs
is passed into it like this.Fix
I think this would require an upstream nixpkgs change or using a vendored, modified
eval-config.nix
to fix*, but it's pretty near the end of a work day here and I have not fully thought it through.*: Where 'fix' means "merge machine-specific nixpkgs elements on top of the network-specified ones"
The text was updated successfully, but these errors were encountered: