-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Is your feature request related to a problem? Please describe.
I'm gathering informations about all the dependencies of a project, such as licences, maintainers, kind (i.e. haskell deps, python deps, ...) and count of the dependencies, ...
It is straightforward to walk the nix structures and gather some information. builtins.genericClosure helps. However I'm missing the dependencies which are implicitly attached to string as string context.
I can recover the context using builtins.getContext, however it does returns a path in the nix store to the derivation, not the original attribute set, so the information I care about is lost.
For example, the expression pkgs.runCommand "foo" {} ''${pkgs.blender}'' implicitly depends on pkgs.blender. However I cannot find a reference to the derivation blender other than using builtins.getContext ((pkgs.runCommand "foo" {} ''${pkgs.blender}'').buildCommand) which returns an attribute set where the drv path is the key: { "/nix/store/8vwn856hd9q6413qqnjiv3l4x7wxq31r-blender-2.91.0.drv" = { ... }; }, unfortunately, the derivation attribute set is lost, including the meta information I care about.
Unfortunately, the .drv does not contain the meta information either.
Describe the solution you'd like
The string context could include a reference to the original derivation which was interpolated as a path?
Describe alternatives you've considered
- I considered rebuilding the information based on the
.drvpath, by looking in all the derivation of my projects (includingnixpkgs), but it is slow (i.e. I need to generate the attribute set of ALL the possible outputPath) and it may not be complete, if a derivation does not exists as an explicit nix reference somewhere (e.g."${pkgs.blender}"will be found when scanningpkgs, but"${pkgs.f x y}"won't, because onlyfwill be found when scanningpkgs.) - I can just accept that it is not complete
- Adding meta informations in .drv
Additional context
The issue with this approach is that it will cost memory for the new entry in the context as well as keeping a reference to the associated attribute set. I did not estimated the memory overhead introduced.