@knedlsepp, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FRidh to be a potential reviewer.

Could you move the outputs to a "py" output? See e.g. libxml2.

@FRidh: I'm not sure what you mean by that. I've been looking how other libraries in nixpkgs that provide python bindings do it and only found opencv and gdal, so I basically copied how it's done in opencv and gdal.

@knedlsepp see #19631 and #20516 (I know realise they're duplicates).

What I meant is that Python bindings are preferably put in a separate output (see multiple outputs in manual and moveToOuput function) to reduce closure size for programs that do not need the bindings.

So, by default we would build with bindings, however, the main output would not contain them. Instead, they're in the package.py derivation/output.

@FRidh: I tried to split the output, but now when I try to run:

export NIX_PATH=nixpkgs=<PATH_TO_NIXPKGS_CLONE>
nix-shell -p pythonPackages.grib-api python --run "python -c 'import gribapi'"

I get an import error for numpy, which should be a propagatedBuildInput. How do I deal with that?

As long as you add a numpy store path somewhere, it typically works. Normally, we use nix/propagated-native-build-inputs. We don't have a nice way for it yet, but what you could do is echo ${numpy} to that file.

I see, that's what is being done in libxml2Python

  libxml2Python = pkgs.buildEnv { # slightly hacky
    name = "libxml2+py-${self.libxml2.version}";
    paths = with libxml2; [ dev bin py ];
    inherit (libxml2) passthru;
    # the hook to find catalogs is hidden by buildEnv
    postBuild = ''
      mkdir "$out/nix-support"
      cp '${libxml2.dev}/nix-support/propagated-native-build-inputs' "$out/nix-support/"
    '';
  };

Honestly I'm a bit hesitant to add all that noise for what would result in a minor saving of disk space. (I just checked: The main library would cosume about 27MB, some tools built upon the lib in bin would consume 6MB and the python bindings are about 0.28MB) I got the feeling that at some point we will want to get rid of this "slightly hacky" solution. Personally at the moment I would rather keep this thing as simple as possible.

@knedlsepp its up to you to choose as maintainer whether you maintain separate outputs or not. I suppose this package is not used as much as libxml2.

We should definitely find a better way. Because its not possible to modify outputs I think in the long term we might want to take the direction I took for pythonPackages.tkinter, i.e., copying the files from the py output into a new derivation.

@FRidh: Would you consider merging?