Skip to content

More context in context string #4677

@guibou

Description

@guibou

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureFeature request or proposallanguageThe Nix expression language; parser, interpreter, primops, evaluation, etc

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions