feat: allow to split buildInputs in python derivations

[yajo]

Follow-up of #676 (comment), now dependencies marked as buildInputs won't be included as propagatedBuildInputs for python derivations.

[DavHau]

If my understanding is correct, and this is merely a build graph / closure size optimization, then I think it is unnecessary to put this complexity in the example.

Concerning excluding all buildInputs from propagatedBuildInputs by default. I wonder if this can have undesired impacts when cross compiling.

For the long term, it might be better if we had a python specific interface to differentiate between install and setup requirements.
... which then maps to equivalent mkDerivation build inputs.

We can hot fix the issue, but I would like to know exactly what problem we are facing before doing so. If nothing is broken, there is no need to fix it.

[yajo]

You could just add this to a d2n module:

{config, ...}: {
  ...
  mkDerivation.buildInputs = [config.deps.python.pkgs.poetry-core];
}

However, very likely you'd get a conflict in some duplicated dependency, if the project you're building requires something that is also required by poetry-core.

Dream2nix, instead, adds all inputs as propagatedBuildInputs. This works for most cases.

The improvement I'm proposing here is that you can now do:

{config, ...}: {
  ...
  mkDerivation.buildInputs = [config.pip.drvs.poetry-core.public.out];
}

And, by doing this, you're implicitly removing poetry-core from propagatedBuildInputs. Thus, optimizing the package is now simpler.

The separation of buildInputs and propagatedBuildInputs should become more relevant after NixOS/nixpkgs#170577 is fixed. When that happens, you will not need to rebuild a wheel just because one dependency gets bumped, unless it's in buildInputs.

[DavHau]

How about adding an option setupDependencies analog to rootDependencies. so the user can simply do this:

pip.setupDependencies = {
  poetry-core = true
}

With the effect that dependencies listed there will be put into buildInputs instead of propagatedBuildInputs.

To me that feels better than manually having to builtins.map (name: config.pip.drvs.${name}.public.out) ....
Also it would prevent possible infinite recursions occurring from making propagatedBuildInputs directly depend on buildInputs.

As a follow up we could then make the locking script put that information into the lock file and populate these fields automatically.

[yajo]

Looks good to me. I'd call it pip.buildDependencies just to keep the name closer to buildInputs. WDYT?

[DavHau]

Sounds good

[yajo]

Refactored.

[DavHau]

Thanks and sorry for the broken CI.
Could you please make sure this passes: nix flake check github:nix-community/dream2nix/pull/684/merge