No access to flake inputs within a perSystem module about flake-parts

[roberth]

The idea behind this restriction is to make sure that all flake-parts modules are in one, compatible form.
This convention avoids weird errors that would arise when importing a perSystem-level module into the top level or vice versa.

• NixOS/nixpkgs#197547 would help, but only in cases where the module has its "class" set; usually not by the author, but possibly by flake-parts itself, via flake.flakeModules or similar.

The statements about the scope only hold true as long as all code is defined inside a single flake.nix file.
The lexical scope breaks as soon as the code is split into modules.

This should work if you define the module as a top-level module. The top-level module provides the lexical scope with these variables, as suggested in the error message.

[roberth]

This decision could be reverted when we have

• error messages for bad imports: NixOS/nixpkgs#197547
• deferredModule options that tag modules with their class

[Atry]

I think the top-level module should always be a flake module, then it can define nested nixosModules/flakeModules. For example:

• https://github.com/Preemo-Inc/nix-ml-ops/blob/main/nixos-modules/nix-ld.nix
• https://github.com/Preemo-Inc/nix-ml-ops/blob/main/flake-modules/options-document.nix

When defining a nested flakeModules, the top level inputs are from the flake that defines the module, and the nested inputs are from the flake that use the module.

[TECHNOFAB11]

I just had the same issue, I wanted to access my util flake from a perSystem module. A workaround is adding this to the imports where the module gets imported:

({...}: {
  _module.args.origInputs = inputs;
})

I could then just use origInputs.<flake>