Closed deliciouslytyped closed 2 years ago
Caveat: depending on implementation, this could mean evaluating extra-container/eval-config under different nixpkgs versions for stage1 and stage2?
Alternatively there could be a second nix file for parameters, though sicne there are only two parameters: the config and the paths, it would only really be setting the path.
Is it that you want to use niv to pin the nixpkgs used for building a container?
A simple way to achieve this would be to generate a extra-container
wrapper via nix (and niv) that sets the --nixpkgs-path
argument. Would that work for you?
Yeah that's an idea. I'll give it a shot later. - but then it's still a multi-step process for the user.
Can you provide more details on what's your imagined, ideal workflow? Do you use direnv or nix-shell? How would the exact arguments to extra-container
look like?
Maybe something like this?
extra-container create <<'EOF'
{ config, pkgs, ... }:
{
nixpkgs = (import ./nix/sources.nix).nixpkgs;
containers.mycontainer.config = {
...
};
}
EOF
I think the better route would be to move forward with flakes as much of the nix community is doing https://github.com/erikarvstedt/extra-container/issues/19
Not all of the community agrees with the flakes approach, and I think pure nix-lang based solutions can be better in some ways.
I haven't poked more at this specific issue since I posted it, and I'd probably patch upstream, as opposed to the nutty stuff I was doing earlier, but I need to take a look again.
So if you really want direct flakes integration, I think there should be means to do both.
Ok, apparently this exists, and I'm not actually sure what it does, but it looks suspiciously like what I want:
containers.<name>.nixpkgs
A path to the nixpkgs that provide the modules, pkgs and lib for evaluating the container.
To only change the pkgs argument used inside the container modules, set the nixpkgs.* options in the container config. Setting config.nixpkgs.pkgs = pkgs speeds up the container evaluation by reusing the system pkgs, but
the nixpkgs.config option in the container config is ignored in this case.
Type: path
Default: "pkgs.path"
Declared by:
<nixpkgs/nixos/modules/virtualisation/nixos-containers.nix>
In hindsight it's obvious that the config =
option could be used with eval-config.
See https://github.com/NixOS/nixpkgs/blob/6fc2b7ecc2a167ce6a6902d5417daf1fa5cac777/nixos/modules/virtualisation/nixos-containers.nix#L529 and https://github.com/NixOS/nixpkgs/blob/6fc2b7ecc2a167ce6a6902d5417daf1fa5cac777/nixos/modules/virtualisation/nixos-containers.nix#L472 .
Though at this point I've forgotten what extra-container does and need to review the source.
That's funny, I just noticed you committed https://github.com/NixOS/nixpkgs/commit/9a283a038d3c028f8b067c6b2e56f2e38bd93192 after not being able to figure out why container.*.nixpkgs wasn't changing anything ~while using an old channel~. Edit: - I'm using unstable and it's still not working, so that's confusing.
Edit 2: some sort of PEBKAC was involved? It seems to work now.
Would it be possible to enable pinning from inside container.nix somehow?
Which is to say, I basically want to override the two external parameters to the containers: https://github.com/erikarvstedt/extra-container/blob/307366f0d4c651b8aa6dd6594b7070404aa8a8a7/eval-config.nix#L1
I see two possible issues with "staged" evaluation: (What I mean by staged is calling eval-config twice.)
If eval-config.nix propagates the two parameters through the lib/eval-config call (it currently does not directly expose these to the callee), a nested call optionally overriding the arguments would at least be possible. It would also need to pass the path to extra-container.
Alternatively, could extra-container inspect container.nix for the two parameters without a full evaluation?
What I actually want, is to use niv.