Closed shivaraj-bh closed 1 week ago
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 https://github.com/shivaraj-bh/flake-schemas/commit/16dc94407c1776cdb0869bb7038c340dacf5c0b4. 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?
Interesting.
In order to support this in
flake-parts
we can makeapps
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).
I didnโt see this message earlier. But I went ahead and created a PR: https://github.com/hercules-ci/flake-parts/pull/240
Edit: You can find my reasoning for freeform type in the PR description
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?
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 sayapp.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.
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)
{
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
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 sayapp.meta.description
. Does this violate any of the constraints in Nix proper?
https://github.com/DeterminateSystems/flake-schemas/pull/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.
Originally posted by @srid in https://github.com/juspay/omnix/issues/157#issuecomment-2233965173
Also see: https://github.com/juspay/omnix/pull/157#issuecomment-2233989200