feat: added plugin to launch nix applications without installing them

[Sntx626]

This plugin creates a local cache of all available applications within nixpkgs and makes them available to be launched by anyrun.

Since most applications aren't downloaded to the /nix/store when you first launch them, expect to wait a few seconds for nix to prepare them in the background.
They should start instantly after the first launch.

[fufexan]

I think nix-run is a better name for the plugin, since that's the command being run in the background.

[Sntx626]

Yes, nix-run is more descriptive. I'll update the pr.

[Sntx626]

All should be updated to nix-run

[fufexan]

Without an activation keyword, doesn't this plugin "conflict" with the applications plugin? Basically you'd get the same programs twice in case you already have the program installed.

[Sntx626]

Without an activation keyword, doesn't this plugin "conflict" with the applications plugin? Basically you'd get the same programs twice in case you already have the program installed.

I'd say it depends.

Yes, it might show redundant applications.
But the list of applications (and their descriptions) might outweigh the doubled entry.
Furthermore it allows the user to launch the same application twice with different versions (since nix-run doesn't need to follow the nix installed apps).

In the long run it would be smarter to add a prefix as a configuration option.
I'll probably add it tomorrow.

[fufexan]

What about nixpkgs#? That way it's explicitly clear what's going on.

[Sntx626]

I though about adding it as a config option similar to how symbols does it.

nixpkgs# would be a good default value (though I personally prefer for it to be the empty prefix, yet again: it wouldn't hurt to implement nixpkgs# as the default and overwrite it in my system config).

[Sntx626]

Nevermind, did it today, implementing a command prefix was trivial with the code provided by the symbols plugin.

[TheRealGramdalf]

This seems very similar to , - since it's also written in rust, would it be possible to integrate such that you don't need to necessarily know the exact package name if it has a different executable (e.g. nix run nixpkgs#gsettings doesn't work, since it's provided by nixpkgs#glib instead)?

This could also be of use for the prefix, as you could simply set it to , by default (the same as comma's CLI)

[Sntx626]

This seems very similar to , - since it's also written in rust, would it be possible to integrate such that you don't need to necessarily know the exact package name if it has a different executable (e.g. nix run nixpkgs#gsettings doesn't work, since it's provided by nixpkgs#glib instead)?

The would be possible, but the index building would need to be redone. Mostly because some outputs are present multiple times, i.e. ls from coreutils, coreutils-full and uutils-coreutils.

We could also look into dynamically fetching the outputs as an optional feature. This could also be extended to work with flakes. I.e. nix-run anyrun-org/anyrun would add all packages/apps outputs defined in the flake to the fuzzy search.

This could also be of use for the prefix, as you could simply set it to , by default (the same as comma's CLI)

This could easilty be done by changing the prefix in the config.
While , as a tool exists, I think that it's better to keep something more descriptive as the default.

---

Though atm my priority to implement this addition is relatively low.

This can still be merged, once we know for certain on how anyrun-org wants to manage non-core plugins.
The current conflicts (*.lock files) can be just overridden from main.