Sorry of this is inappropriate, but how about moving this into stdenv.mkDerivation and have the path verified (that it exists) at build time? Usage could be e.g. pkgs.bash.app.

That's an entirely reasonable question and also one that @domenkozar was making in his comment in the previous PR: #67392 (comment) (which also stalled the previous PR).

Assuming that lib.toApp gets merged today, it doesn't prevent to extend the heuristic (and port it back to nix run).

Previously I thought that build-time checking would necessarily require double the number of derivations. But your question actually gave me the idea that it could be possible to just make it an extra stdenv.mkDerivation attribute that can be verified in the checkPhase.

This seems to be about making script writing easier, but the flakes app feature doesn't seem to be intended for this. Instead it's intended for desktop apps (or similar?) and potentially sandboxing those.

To keep the terminology consistent, we need a different name for this function (or derivation attribute for that matter). I suggest command or program.

For both apps and derivations it makes sense to have a program attribute. So perhaps this should be toProgram and stdenv could provide a checked attribute named program.

command isn't a thing yet afaik, but I think it makes sense to have defaultCommand next to defaultApp, considering that some desktop apps come with a cli and both flake attributes have different needs wrt sandboxing.

A toApp function may make sense, to turn a derivation with a program into a flake app input instead: p: { type = "app"; program = inherit (p) program; }

I marked this as stale due to inactivity. → More info

#167247