This is quite a radical change I'm considering for poetry2nix v2:

The API comes down to one central function mkOverlay:

let
  python = pkgs.python3.override {
    self = python;
    packageOverrides =
      lib.composeExtensions
      (poetry2nix.mkOverlay {
        projectRoot = ./.;
      })
      poetry2nix.overrides
  };
in
   ...

In this brave new world I'm having two considerations I'm not sure about:

• Where does preferWheel(s) belong? Is this actually the correct mechanism for sdist/wheel preference order?
• Where does PEP-508 marker customisation belong?
  This is not currently something you can do with poetry2nix, but it's something I'm adding.

In reply to @truh:matrix.org
So I would then use python.pkgs.<my-project-name> instead of the output of mkPoetryApplication?

In reply to @truh:matrix.org
Sounds good, maybe a bit more difficult to get the hang of for people who aren't familiar nixpkgs.

In reply to @truh:matrix.org
Would this create ovrrides for all depedencies in the poetry.lock? What do you think about a way to tell poetry2nix to not create overrides for particular packages, when I know python3Packages.particular-package would work for my project, requires less build time on my end, and is well maintained. Or does that lead problems

Excerpt:

# Create a Python overlay from pdm.lock filtered by what already exists in nixpkgs.
# This means that our overlay strictly extending nixpkgs for maximal binary cache hits.
let
  inherit (lib) flip elem attrNames filterAttrs;

  project = pyproject-nix.lib.project.loadPDMPyproject {
    projectRoot = ./.;
  };

  overlay' =
    lib.composeManyExtensions [
      (pdm2nix.lib.lock.mkOverlay {
        inherit project;
        preferWheels = true;
      })
    ];

in pyfinal: pyprev: let
  attrExists = flip elem (attrNames pyprev);
  applied = overlay' pyfinal pyprev;
in
  filterAttrs (n: _: ! attrExists n) applied // {
    # Nixpkgs has an ancient & broken version
    inherit (applied) ezdxf;
  }