erikarvstedt / extra-container

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:

nixosPath: systemConfig:

I see two possible issues with "staged" evaluation: (What I mean by staged is calling eval-config twice.)

is there extra work being done? (does laziness help?)
do the things set in the top level eval-config interact in some funky way with the nested one? how do you completely ignore the top level and just return the nested call result?

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.

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 #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 NixOS/nixpkgs@9a283a0 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.

Fixed by 93f72a8.

Nixlang-based pinning