utility app to `mkApp` self.packages automatically about flake-utils HOT 5 CLOSED

The whole apps and mkApp has become somewhat redundant. Historically, nix run was relying on that construct to run things. Since then It has acquired its own heuristic and can lookup the packages and legacyPackages. You can try this out by running nix run nixpkgs#hello. So I would just expose the packages and let deal with resolving the right one.

One case where I think mkApp is still useful, is when a derivation output contains multiple binaries. For example, you might have yourflake#coreutils and also want to expose yourflake#ls and yourflake#mkdir`. In that case, I expect the correspondence to be drawn manually.

from flake-utils.

Without an app declaration, nix run seems to call the value of name by default to evoke the binary, which in a lot of cases is "${name}-{pname}". There is an effort to standardize this. NixOS/nixpkgs#103997. In particular, it fails for me.

We should probably call a package by its pname instead. NixOS/nix#4422

from flake-utils.

Do you want to do something about this? I think the conclusion of NixOS/nix#4422 (comment) might apply here as well.

from flake-utils.

It seems I'm just hitting this:

$ nix run .#CashBoxy:exe:Main
warning: Git tree '/home/blaggacao/ghq/git.p1.rocks/SideProjects/CashBoxy' is dirty
trace: gitSource.nix: /nix/store/bbln8w5gf3fainh1206f42q4zry0gmgi-source does not seem to be a git repository,
assuming it is a clean checkout.
trace: To materialize project.plan-nix for CashBoxy entirely, pass a writable path as the `materialized` argument and run the 'updateMaterialized' script in 'passthru'.
error: --- SysError ----------------------------------------------------------------------------------- nix
unable to execute '/nix/store/baskvl2ay7mrprgjaq75w5ndclxp39m5-CashBoxy-exe-Main-0.1.0.0/bin/CashBoxy-exe-Main': No such file or directory

But

$ ls /nix/store/baskvl2ay7mrprgjaq75w5ndclxp39m5-CashBoxy-exe-Main-0.1.0.0/bin
Main

so its /bin/Main vs bin/CashBoxy-exe-Main

It's all new to me, but I conclude that program = v.exePath still has it's validity?

from flake-utils.

If any similar issues arise in the future, they should be routed to upstream nix to improve the hueristic for launching packages.

from flake-utils.