Proposal: Automatically enrich pyproject overlays with upstream Nixpkgs metadata (e.g., licenses)

[oneingan]

Hi,

I'm using pyproject.nix to manage Python overlays in Nixpkgs, and I've noticed that derivations generated via mkPyprojectOverlay lack important metadata attributes like meta.license. This is due to pyproject.nix relying exclusively on metadata from pyproject.toml (or lock files), which doesn't include fields like licenses.

The Problem

This results in all overlay derivations missing metadata like licenses, affecting downstream usage such as license compliance or integration with Nixpkgs tools. Users must currently override this manually.

Proposed Solution

To address this, I've implemented a wrapper that enriches the overlay with metadata from the upstream python.pkgs set in Nixpkgs, where available. It adds missing licenses (and could be extended to other fields):

overlay = workspace.mkPyprojectOverlay {
  sourcePreference = "wheel"; # or sourcePreference = "sdist";
};

overlayWithLicense =
  final: prev:
  let
    upstreamPy = python.pkgs;
    overlayAttrs = overlay final prev;
    licenseFor = name: lib.attrByPath [ name "meta" "license" ] null upstreamPy;
    enriched = lib.mapAttrs (
      name: drv:
      let
        lic = licenseFor name;
      in
      if (drv.meta or { }) ? license || lic == null then
        drv
      else
        drv.overrideAttrs (old: {
          meta = (old.meta or { }) // {
            license = lic;
          };
        })
    ) overlayAttrs;
  in
  enriched;

This is non-destructive, only adding metadata where missing and upstream info exists.

This feels like a useful enhancement that could be integrated upstream, similar to other features (e.g., #358 for handling overrides or metadata injections). Perhaps as an optional flag in mkPyprojectOverlay (e.g., enrichFromUpstream = true;) or a utility function.

Benefits

• Ensures more complete metadata without manual intervention.
• Improves interoperability with Nixpkgs' Python ecosystem.
• Flexible for extension to other metadata fields.

Feedback welcome—happy to refine or open a PR!

Thanks!

[oneingan]

Same idea is valid for recent meta.identifiers

[adisbladis]

Though the proper way to accomplish richer metadata is adding it to uv and have uv2nix understand it natively.
There are a few open related issues/PRs for uv:

• Add uv license or similar to audit dependency licenses astral-sh/uv#8156
• Draft: Add uv license command astral-sh/uv#10292

In the mean time I can see how this would be useful, but it comes with some drawbacks:

• Imprecise
  You're not using the same package versions so any metadata may be incorrect.
• Nixpkgs meta contains attribute for internal use
• I consider Nixpkgs Python packages a legacy format, and not something that should ever be used except indirectly.

Because of these drawbacks I think this feature would belong in hacks.
This is not something I'm going to work on, but I would accept a PR adding it.