deprecate mkApp in favor of direct definitions

[soupglasses]

Now that nixpkgs has its own idea of passthru.exePath under the name meta.mainProgram, deprecate our solution in favor of the new standard.

This subsequently removes the value of which mkApp brings, and therefore a full deprecation for its removal has begun.

Closes: #65

[soupglasses]

That became a few more force pushes than desired, but it should all be good now! 😅

[zimbatm]

Thanks! Left a few comments, the PR should be ready once these have been addressed.

[zimbatm]

Don't you think it would be nicer to deprecate drv.passthru.exePath and use nixpkgs.lib.getExe in the helper instead?

This is still a bit simpler to use.

[zimbatm]

That being said, I don't see a lot of value in definining those apps.

[soupglasses]

Yeah. There is a problem where all these apps can be rewritten as packages."<system>"."<name>" since nix3-run runs against meta.mainProgram as well.

Unsure how to show examples without removing apps outright.

[zimbatm]

I forgot; the main use-case for apps is for packages that output multiple binaries. For example mkApp { drv = coreutils; name = "ls"; }.

So I propose to just deprecate any uses of drv.passthru.exePath.

[zimbatm]

ok, that seems ready to me. have a look and tell me what you think.

[soupglasses]

I am honestly still quite a bit for deprecating the entire mkApp still. And recommending the use of { type = "app"; program = "${drv}/bin/name"; } or using packages. with mainProgram instead.

As there is little gain having a mkApp function compared to just using the direct definition it creates. For example:

{
  outputs.apps.x86_64-linux = {
    with-lib = flake-utils.lib.mkApp { drv = pkgs.coreutils; name = "ls"; };
    no-lib = { type = "app"; program = "${pkgs.coreutils}/bin/ls"; };
  };
}