lib/deprecated: alias mapAttrsFlatten to mapAttrsToList

[tie]

Description of changes

These functions have identical implementation except for argument names.

This PR also updates usage in Nixpkgs.

mapAttrsFlatten:

nixpkgs/lib/deprecated/misc.nix

Lines 214 to 215 in b281753

	# calls a function (f attr value ) for each record item. returns a list
	mapAttrsFlatten = f: r: map (attr: f attr r.${attr}) (attrNames r);

mapAttrsToList:

nixpkgs/lib/attrsets.nix

Lines 1093 to 1096 in b281753

	mapAttrsToList =
	f:
	attrs:
	map (name: f name attrs.${name}) (attrNames attrs);

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[philiptaron]

This looks right to me, given https://noogle.dev/f/lib/mapAttrsToList. I take no position on the warnIf.

[philiptaron]

Pulled in because of a top-level with statement 😿

[tie]

Welp 🤷
See also #208242

[philiptaron]

See also who it's assigned to. 😉

[tie]

@philiptaron, are we waiting for a review from @infinisil (ping :]) before merging?

[infinisil]

I think a lib.warn would be best! (We'd only need a lib.warnIf (isInOldestRelease 2411) if the replacement were introduced in the same change)

[tie]

@infinisil, done. I’ve used isInOldestRelease 2405 since we probably want to start printing warnings for NixOS 24.11 release (and unstable release channel) and hopefully remove this function in future releases to avoid confusion.

[infinisil]

Ah no we really just need an unconditional lib.warn here. The isInOldestRelease thing is a bit confusing, but it's not needed here, see also #291939

[infinisil]

Specifically isInOldestRelease is asking "is the new feature that replaces the old one in the oldest supported release?", which is always true if the replacement already exists in all supported releases

[tie]

Ah, sorry, misunderstood your suggestion.

[tie]

@infinisil, changed to warn about deprecation instead of warnIf.