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
.drv path, by looking in all the derivation of my projects (including nixpkgs), 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 scanning pkgs, but "${pkgs.f x y}" won't, because only f will be found when scanning pkgs.)
- 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.
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.genericClosurehelps. 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 onpkgs.blender. However I cannot find a reference to the derivationblenderother than usingbuiltins.getContext ((pkgs.runCommand "foo" {} ''${pkgs.blender}'').buildCommand)which returns an attribute set where thedrvpath is the key:{ "/nix/store/8vwn856hd9q6413qqnjiv3l4x7wxq31r-blender-2.91.0.drv" = { ... }; }, unfortunately, the derivation attribute set is lost, including themetainformation I care about.Unfortunately, the
.drvdoes not contain themetainformation 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
.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.)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.