2 level deep packages in nix flakes · nix

My ticket here got closed, which I understand. But now I wonder if there is any way to make it more flake compliant? I have no problem running my flake at the moment (only nix flake show gives a error: expected a derivation around the pythonPackages as it expects a derivation, but I can build packages fine).

Let me explain the background behind this. I'm in a situation where I sometimes have the same package name for a python library and for its associated CLI.
So I want the CLI tool to stay in packages.${system}.* and the library to go in packages.${system}.pythonPackages.*.

What would be a better way to handle this? Should I have derivations with multiple outputs or something?

Note: I'm using flake-utils.lib.eachDefaultSystem, which is why you don't see the ${system} in the code pasted in the ticket.

Shivaraj B H (Jan 04 2024 at 10:21):

Shivaraj B H (Jan 04 2024 at 10:27):

From what I interpret from the logs, it looks more of a type issue which is breaking while devour-flake is trying to evaluate the derivation given by nix build .#default

pcboy (Jan 04 2024 at 11:40):

Yes I have no problem building all my packages. But of course, doing nix build .\#pythonPackages will not work (as it's not a derivation), nix build.\#pythonPackages.package1 will work (as it's a derivation).
What's happening, as far as I understand, is that devour-flake does not like the fact that packages.${system}.pythonPackages is not a derivation, because in a flake it seems it's not authorized/standard to have more than one level deep packages... This could I guess be solved if devour-flake had some sort of recursive way of finding derivations inside packages.**, instead it seems it stops at one level deep (e.g packages.${system}.app1). But at the same time I understand that devour-flake does not want to support something not deemed standard.
Here what I'm wondering more then is what would be the recommend way?
It seems in nixpkgs, they are putting the packages into legacyPackages instead of packages, and in there they do have multiple levels of packages. But devour-flake would not work with that either I suppose?

{
{
  description = "A basic flake with a shell";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
  inputs.flake-utils.url = "github:numtide/flake-utils";

  outputs = {
    nixpkgs,
    flake-utils,
    ...
  }:
    flake-utils.lib.eachDefaultSystem (system: let
      pkgs = nixpkgs.legacyPackages.${system};
    in {
      packages.app1 = pkgs.stdenv.mkDerivation {
        name = "app1";
        src = pkgs.hello;
        installPhase = "mkdir -p $out/bin && install -m755 $src/bin/hello $out/bin/hello";
      };

      packages.app2 = pkgs.stdenv.mkDerivation {
        name = "app2";
        src = pkgs.hello;
        installPhase = "mkdir -p $out/bin && install -m755 $src/bin/hello $out/bin/hello";
      };

      packages.pythonPackages = {
        app3 = pkgs.stdenv.mkDerivation {
          name = "app3";
          src = pkgs.hello;
          installPhase = "mkdir -p $out/bin && install -m755 $src/bin/hello $out/bin/hello";
        };
      };
    });
}

Srid (Jan 04 2024 at 13:09):

Srid (Jan 04 2024 at 13:10):

Srid (Jan 04 2024 at 13:12):

Because, once we start using flake-schemas - if for some reason your flake doesn't adhere to the standard schema, you can always define your own schema, and devour-flake (thus nixci) can use that.

Stream: nix