`om show`: display description for flake apps

[shivaraj-bh]

What will it take for us to show a description for flake apps, such as haskell-template below? Packages already have them.

Originally posted by @srid in #157 (comment)

Also see: #157 (comment)

[shivaraj-bh]

I was able to display description for a flake app in a flake that doesn’t use flake-parts:

🐚 nix --extra-experimental-features 'nix-command flakes' show-config --json
🐚 /nix/store/n02w2ybg9fc78grzz9i2aj49q3rysp7m-nix-2.24.0pre20240801_af10904/bin/nix flake show --legacy --allow-import-from-derivation --json --default-flake-schemas /nix/store/y8j5b7canf0la2dfnbd004m9n5zlm8l1-source .
🚀 Apps (nix run .#<name>)
╭───────┬──────────────╮
│ name  │ description  │
├───────┼──────────────┤
│ hello │ I say hello! │
╰───────┴──────────────╯

This involved a one-line addition to flake-schemas, see shivaraj-bh/flake-schemas@16dc944. The flake.nix used above is:

{
  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
  outputs = { self, nixpkgs, ... }:{
    apps.aarch64-darwin.hello = {
      program = "${nixpkgs.lib.getExe nixpkgs.legacyPackages.aarch64-darwin.hello}";
      type = "app";
      description = "I say hello!";
    };
  };
}

In order to support this in flake-parts we can make apps option a free-form type?

[srid]

Interesting.

In order to support this in flake-parts we can make apps option a free-form type?

You should open an issue on https://github.com/hercules-ci/flake-parts proposing to support app descriptions using any specific approach, then Robert can provide feedback.

(Why a freeform type though? Isn't adding description here sufficient? But let's discuss this in flake-parts repo).

[shivaraj-bh]

I didn’t see this message earlier. But I went ahead and created a PR: hercules-ci/flake-parts#240

Edit: You can find my reasoning for freeform type in the PR description

[srid]

This involved a one-line addition to flake-schemas, see shivaraj-bh/flake-schemas@16dc944.

Can you open PR on flake-schemas proposing this change? That discussion there might be relevant. I'm wondering why app.description, rather than say app.meta.description. Does this violate any of the constraints in Nix proper?

[shivaraj-bh]

This involved a one-line addition to flake-schemas, see shivaraj-bh/flake-schemas@16dc944.

Can you open PR on flake-schemas proposing this change? That discussion there might be relevant. I'm wondering why app.description, rather than say app.meta.description. Does this violate any of the constraints in Nix proper?

We could use app.meta.description to stick to the convention of how its done in derivations. I was just checking to see if custom attributes in apps.<name> even works.

[srid]

I was just checking to see if custom attributes in apps.<name> even works.

See if nix flake check fails if you there are custom attributes. At least it does for templates (see #200)

[shivaraj-bh]

{
  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
  inputs.flake-parts.url = "github:shivaraj-bh/flake-parts/freeform-app-type";
  outputs = { flake-parts, ... }@inputs: flake-parts.lib.mkFlake { inherit inputs; } {
    systems = [ "aarch64-darwin" ];
    perSystem = { pkgs, ... }: {
      apps.hello = {
        program = pkgs.hello;
        type = "app";
        description = "I say hello!";
      };
    };
  };
}

Tried it with ^

~/oss/tmp
❯ nix flake check

~/oss/tmp
❯ echo $?
0

[shivaraj-bh]

This involved a one-line addition to flake-schemas, see shivaraj-bh/flake-schemas@16dc944.

Can you open PR on flake-schemas proposing this change? That discussion there might be relevant. I'm wondering why app.description, rather than say app.meta.description. Does this violate any of the constraints in Nix proper?

DeterminateSystems/flake-schemas#31

[srid]

• apps: Add meta option hercules-ci/flake-parts#240
• nix flake show: Support meta attribute for apps NixOS/nix#11297

[srid]

DeterminateSystems/flake-schemas#31 is the only thing blocking this PR? I think it should be fine for us to maintain a temporary fork (of flake-schemas; preferably in @juspay org) until upstream merges our PRs.