Is it feasible to add support for pyproject-nix virtual environments via NIX_PYPROJECT_DEPS?

[oneingan]

Hi,

I'm using Bombon to generate CycloneDX SBOMs from Nix derivations, and it works well by extracting dependencies (e.g., from buildInputs). However, with recent pyproject-nix versions for Python virtual environments, dependencies are now in a custom NIX_PYPROJECT_DEPS attribute—a colon-separated list of store paths—while buildInputs remains empty. This helps avoid "Argument list too long" build errors.

For instance, in a signal-api.venv derivation:

nix-repl> packages.x86_64-linux.signal-api.venv.drvAttrs
{
  NIX_PYPROJECT_DEPS = "/nix/store/6kjihd3q1025qdhvh3djd60d1nf2zp5n-signal-api:/nix/store/7aazmwaysz7fw514r0b96iji5xdwl161-fastapi-0.115.12:...";  # full list of deps
  buildInputs = [ ];  # empty
  ...
}

This stems from pyproject-nix commit f91edf6: "build.lib.mkVirtualEnv: Don't add Python packages to buildInputs".

I recognize this is a bit unconventional on pyproject-nix's end, and you might not want to accommodate every Nix framework variation. Would it be possible to add parsing for NIX_PYPROJECT_DEPS (splitting by :) to include those as components/dependencies in the SBOM? I'd appreciate any thoughts on feasibility.

Thanks!

[nikstur]

It feels like pyproject.nix should still include these in buildInputs. "Hiding" them in string contexts is not ideal.

I wonder if __structuredAttrs could solve their problem with too many values.