inputDerivation: support structuredAttrs

[roberth]

Description of changes

Draft solution. I think we'll want to route coreutils into here, so we can mkdir and get rid of dog.

#206728 also happens to route more stuff into here, so I think we should perhaps just bring a pkgs into scope, so as not to duplicate too many things. Downside is a potential infinite recursion comes into scope, but using file structure to "enforce" a lack of those is probably not the best strategy.

• Incorporates a commit from make-derivation.nix: Support inputDerivation on disallowedReferences #215168

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[roberth]

re @infinisil

I'm actually not sure what use cases inputDerivation has now that mkShell is buildable. They are using essentially the same approach though, it would be good to keep them in sync somehow

There's a performance cost associated with largely unused attributes like this one, so without a reason for this to be an attribute, I think it's better to remove it.

Alternatively, we could replace it by a devShell attribute, which unlike this one has a reason to be a derivation attribute, which is to allow customization of nix behavior via passthru. See

• POC: devShell interface #206728

The difference is that the customization of devShell can only be achieved by tying it to the derivation, but the user experience is otherwise quite similar.

[wolfgangwalther]

Superseded by #361233