[RFC] types.listOf: actually validate the contents

[K900]

Description of changes

This is a footgun. Remove the footgun. I solemnly swear to do my best to deal with the inevitable fallout.

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/)
• 22.05 Release Notes (or backporting 21.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.

[K900]

This will probably break things. Things that are broken by this probably deserve it.

[Deep-Six]

@K900 thanks for resolving this! It was driving me mad!

[K900]

For context, @Deep-Six was hitting a completely inscrutable error after doing environment.systemPackages = [ pkgs.rust ], with pkgs.rust being a random attribute set of assorted Rust stuffs and not a package.

[Mindavi]

Aww, this is all I get from nixpkgs-review:

Result of nixpkgs-review pr 168295 run on x86_64-linux 1

1 package blacklisted:

• nixos-install-tools

I think it'll only be in the modules, which probably requires running (some) nixos tests.

Anyway, +1 from me, seems like a good idea to check this.

[K900]

The comment saying check-meta should be enabled "soon" is from 2017... Right now I've enabled it just to see more things fail (or not?), but maybe it should stay that way?

CC @copumpkin who wrote the original comment all those years ago.

[K900]

OK, so it turns out the validation does work correctly here, the problem is with toPretty specifically exploding when passed pkgs.rust for ... whatever reason?

[roberth]

toPretty probably fails miserably on data structures that involve repetition and recursive references. Maybe that's what happened?

In error messages, we shouldn't enter more than two layers of attrsets and/or lists, to avoid infinite recursions and to avoid some unnecessarily large messages.

[K900]

Yes, that is what happened. I've submitted a fix (ish) for toPretty in #168327