Cannot access non-system output of flakeModule in submodule

[DavHau]

To reproduce the issue:

$ git clone https://github.com/DavHau/drv-parts --branch problem
$ cd drv-parts
$ nix flake show ./examples/htop --override-input drv-parts ./.

error:

error: attribute 'modules' missing

       at /nix/store/ni13vsgnf6hv42gpnlsv42yvv73w43m0-source/examples/htop/htop.nix:6:47:

            5|   # select mkDerivation as a backend for this package
            6|   imports = builtins.trace inputs'.drv-parts [inputs'.drv-parts.modules.mkDerivation];
             |                                               ^
            7|

The problem is, that I want to access an output of my flakeModule drv-parts, but the inputs' variable only contains system prefixed outputs, like devShells and packages. Other outputs like nixosModules for example are missing.

Am I using this wrong? If not, could we also add non-system specific outputs to inputs'?

[roberth]

We could copy the `inputs` argument into the submodule. Or perhaps you could get it from the top level module arguments, through the lexical scope. Will have a look at the code later.

…

-------- Original Message --------

On 30 Nov 2022, 16:46, DavHau wrote: To reproduce the issue: $ git clone https://github.com/DavHau/drv-parts --branch problem $ cd drv-parts $ nix flake show ./examples/htop --override-input drv-parts ./. error: error: attribute 'modules' missing at /nix/store/ni13vsgnf6hv42gpnlsv42yvv73w43m0-source/examples/htop/htop.nix:6:47: 5| # select mkDerivation as a backend for this package 6| imports = builtins.trace inputs'.drv-parts [inputs'.drv-parts.modules.mkDerivation]; | ^ 7| The problem is, that I want to access an output of my flakeModule drv-parts, but the inputs' variable only contains system prefixed outputs, like devShells and packages. Other outputs like nixosModules for example are missing. Am I using this wrong? If not, could we also add non-system specific outputs to inputs'? — Reply to this email directly, [view it on GitHub](#81), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AADZGP662ODKEYLCGM6FXBDWK6AGVANCNFSM6AAAAAASP2ZAKM). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[roberth]

Hmm, this seems to be in a (novel) "package" module. I don't think those should have direct access to such global variables as inputs', inputs, or even pkgs. Once you rely directly on those, overridability in the sense of the (classic) pkg.override goes out of the window.
For this purpose, you could create a package option called deps that is the only option to be defined in terms of pkgs and/or inputs, etc.

deps = mkOption {
  description = ''
    All dependencies of the package. This is the only option that gets to access the "outer world", such as `pkgs` or the flake `inputs`.

    By separating the task of retrieving things from the outside world, you ensure that the package is overridable.
    Nothing will stop you from adding `pkgs` itself as a dependencies, but this will make it very hard for the user of the package to override any dependencies, because they'd have to figure out a way to insert their changes into the Nixpkgs fixpoint. By adding specific attributes to `deps` instead, the user has a realistic chance of overriding those dependencies.
    
    So deps should be specific, but not overly specific. For instance, the caller shouldn't have to know the version of a dependency in order to override it. The name should suffice. (e.g. `nix = nixVersions.nix_2_12` instead of `inherit (nixVersions) nix_2_12`.
  '';
  type = types.coercedTo (types.functionTo (types.lazyAttrsOf types.raw)) kindOfLikeCallPackageButActuallyWeOnlyPassPkgsAndInputsAndInputs' (types.lazyAttrsOf types.raw);
  default = {};
  example = lib.literalExpression ''
    { pkgs, inputs', ... }: {
      inherit (pkgs) stdenv;
      inherit (pkgs.haskellPackages) pandoc;
      nix = inputs'.nix.packages.default;
    }
  '';
}

[DavHau]

Thanks, that's amazing advice. I'll try to incorporate that. If you have more ideas like that, please let me know ;)

[montchr]

the inputs' variable only contains system prefixed outputs, like devShells and packages. Other outputs like nixosModules for example are missing.

FWIW I’ve run into this behavior when trying to access inputs'.nixpkgs.lib -- lib was not accessible in that case, so I had to reach up to the top-level inputs.nixpkgs to get lib.

[roberth]

Leaning into the difference between top level and perSystem until we can blur the distinction thanks to improved error messages; see #101 (comment)