Feature request: index by mime associations

[KiaraGrouwstra]

nixpkgs, even without flakes, has a lot of packages.
this might make it somewhat daunting for users to find what they need.
now, fortunately nix packages follow a fairly regular structure, placing e.g. .desktop files in a package's $out/share/applications.
this makes me wonder: if such a desktop file knows what mime types it applies to, might it not make sense to index the nixpkgs offering by these?
ideally, given an arbitrary file or scheme, this might make it easier for users to find software packages they could use these with.

(cross-posted as per @fricklerhandwerk's suggestion.)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/index-nix-applications-packages-by-mime-associations/35725/3

[jtojnar]

Related: NixOS/nixpkgs#15932

[ehmry]

How about an attrset in meta that maps mime types to programs?

{
  name = "foobar";
  meta = {
    mainProgram = "foo";
    mimeHandlers = {
      "application/x-foo" = "foo";
      "x-scheme-handler/urn:foo" = "foo";
      "application/x-bar" = "bar";
    };
  };
}

I don't think any of the Gnome/Freedesktop stuff is useful here as we have to build the package to get those artifacts and they are anyway too complicated or too biased to Gnome.

[jtojnar]

We do something similar with pkg-config modules. But there is a cost of duplicating the metadata materialized in a Nix package expression – both in increasing the complexity of the expression and continually working on keeping it in sync. And since a typical app often supports many more MIME types than a typical library provides pkg-config modules, and new supported types are introduced more frequently, the cost is higher here.

I don't think any of the Gnome/Freedesktop stuff is useful here

The whole purpose of AppStream and Freedesktop.org Desktop Entry Specification is to have a single standard metadata format for description of software components and application launchers respectively. (Not sure why you are bringing up GNOME when GNOME is just one of the many parties involved.) With NixOS/rfcs#146, we appear to be trending towards reimplementing a subset of the specifications.

For this purpose, we could even just use desktop files which are pretty simple to parse, and then cache them using something like nix-index. Yeah, there are a few more moving parts than with plopping increasingly more metadata into the expressions (we would probably need hydra support for it to be efficient) but we will probably want the other features of NixOS/nixpkgs#15932 for search as well.

Is there really the need to have that data available at evaluation time? Is the need sufficient to justify the costs? It might be but we should consider it carefully, just like we do with NixOS/rfcs#146.

[ehmry]

The whole purpose of AppStream and Freedesktop.org Desktop Entry Specification is to have a single standard metadata format for description of software components and application launchers respectively.

Those standards only describe things in the context of a full-blown cargo-cult desktop with heaps of assumptions about wonky stuff like dbus. You don't need to look any further than the ".desktop" extension.

Is there really the need to have that data available at evaluation time?

Yes, the tradeoff is the cost of evaluating meta across an entire package set versus building an entire package set and parsing build artifacts. I wouldn't take a public hydra with enough power to build nixpkgs for granted, given the political situation and rate at which nixpkgs is expanding.

To be fair what I've proposed isn't sufficient as you probably need to support command line flags and parameter substitutions.