Before this commit, getExe assumes that if meta.mainProgram is unset, it has a main program that's named after the package name.

While this is probable, it leads to a bad error when the assumption does not hold. If the user called getExe themselves, they might narrow down the location of the assumption quite easily, but if that's not the case, they'll have to go down the rabbit hole to figure out what went wrong.

For example, a NixOS module may use lib.getExe on a package-typed option which is then used in the system configuration. This then typically leads to a failure after deployment, which is bad, and it's quite likely that the user will debug the package output contents before digging through the NixOS module, which is bad.
Furthermore the getExe call is rather inconspicuous as it does not contain something like "/bin/foo", which is bad.
Also modules can be hard to read for a newbie, which is bad.

All of this can be avoided by requiring meta.mainProgram. Many packages already have the attribute, and I would expect 80% of getExe usages to be covered by 20% of packages, because plenty of packages aren't used with getExe anyway.

Finally we could make an effort to set mainProgram semi-automatically using nix-index.

Description of changes

Adds a warning to the unreliable behavior.

[nixpkgs]$ nix repl .
nix-repl> lib.getExe (hello // { meta = {}; })
trace: warning: getExe: Package hello does not have the meta.mainProgram attribute. We'll assume that the main program has the same name for now, but this behavior is deprecated, because it leads to surprising errors when the assumption does not hold. If the package has a main program, please set `meta.mainProgram` in its definition to make this warning go away. Otherwise, if the package does not have a main program, or if you don't control its definition, specify the full path to the program, such as "${lib.getBin foo}/bin/bar".
"/nix/store/nj2460zk9fjdl9yyglsi2nh4lp78na24-hello-2.12.1/bin/hello"

Context

• Introduced in lib/meta: add getExe to get the main program of a drv #167247

  • Short conversation leading to this PR

• Tangentially related to the point of off-topic: Make getExe (writeScript x y) work #173675

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.11 Release Notes (or backporting 23.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.