How to combine with drv-parts and flake-parts without incurring in infinite recursion?

[yajo]

I'm testing v1 and having one PITA so let me share it here just in case I'm doing something wrong.

Well, the thing is that drv-parts recommends using it through flake-parts. However, when doing that, I couldn't find a way to make the dream2nix argument visible to the modules that require it, such as pip. It always gets to an infinite recursion error.

So, since drv-parts is recommended to be used by flake-parts, I think it would be great to have an example on how to combine those 2 projects together with dream2nix without incurring in infinite recursion.

[DavHau]

Sorry, the drv-parts readme is a bit outdated. We also don't really use the flake-parts interface it delivers. I should remove that.
Just use dream2nix.lib.evalModules to evaluate your modules. That will provide you with the dream2nix arg.

[DavHau]

Hm, then we should possibly port it over as soon as dream2nix v1 is released. Maybe we should just integrate drv-parts into dream2nix alltogether!?

[yajo]

Somehow it is weird that you need to do a call in dream2nix to be able to inject new arguments into drv-parts.

I'd expect that drv-parts included such a system, which should be easy to plug in flake-parts.

[yajo]

About mixing both projects, maybe it would help. However, I think both make sense separated as both have slightly different goals. If there was a way to integrate all of them more ergonomically, this merge probably wouldn't be needed.

[DavHau]

Hm, maybe there is a way to manage inputs to modules better than via specialArgs. It would probably be best if the module system itself had a input management.
One core problem seems to be that flakes and modules are separate features which are not integrated with each other. It would be nicer if flakes was a feature of the module system or vice verca.

[yajo]

I think I was becoming crazy until I realized 2 important things:

1. dream2nix.lib.evalModules is the d2n equivalent to nixpkg's callPackage. It gets modules and outputs a derivation.
2. dream2nix.flakeModuleBeta (the one that's documented) targets the old d2n. The new d2n (v1) doesn't have a flake module.

If these things were called modules2drv and flakeModuleDeprecated, I think I'd have grasped it faster. I'm not telling to rename them, but please keep this in mind when you finally do the docs, because it's not obvious.

For example, evalModules doesn't tell you what will be the result of that "eval". And since there are flake-parts modules, drv-parts modules and dream2nix modules (which are drv-parts but different), not to count with devshellModules and nixosModules... it gets confusing.

Also the "Beta" part of the flake module seems to point to something that is pre-production, not to something that is deprecated.

[yajo]

I found out a nice way to integrate d2n with flake-parts: packageSets + deps.

Observe this flake-parts module:

{
  inputs,
  lib,
  self,
  ...
}: {
  perSystem = {
    self',
    pkgs,
    system,
    ...
  }: {
    packages.default = inputs.dream2nix.lib.evalModules {
      modules = [{imports = [../drvs/something];}];
      packageSets = {
        inherit inputs self self'; # Here is the magic 🪄
        nixpkgs = pkgs;
      };
  };
}

By doing this, you can define a drv-parts module that has anything it'd need from flake-parts. It just has to declare what it needs in deps:

{config, ...}: {
  deps = {nixpkgs, inputs, self, self', ...}: {
    inherit inputs;
    inherit (nixpkgs) hello;
    selfLib = self.lib;
    defaultPackage = self'.packages.default;
  };

  # Now use those deps anywhere you want; any infinite recursion will depend on you from now on
  name = config.deps.selfLib.name;
  
  # dream2nix and drv-parts are available from config.deps.inputs too, no need for a top-level arg
  imports = [
    config.deps.inputs.dream2nix.modules.drv-parts.lock
    config.deps.inputs.drv-parts.modules.drv-parts.mkDerivation
  ];

  # Use flake outputs as dependencies
  mkDerivation.buildInputs = [config.deps.defaultPackage];
}