Closed dorranh closed 1 year ago
If I understand correctly, in the example, package with name=emacs-numpydoc-20230320.1439
has a pname=numpydocs
.
Note this is to be expected for any build*Package
(e.g. buildPythonPackage
).
Now I guess your point is that the UI displays a "numpydoc" node, but it should really be "emacs-numpydoc".
To fix this confusion I propose to
parsedName.name
instead of pname
https://github.com/tweag/nixpkgs-graph-explorer/blob/cca62d7dc92c0e4010c9d20c8ac9befcef8aa321/core/explorer/extract/nixpkgs-graph.nix#L53Additionally, we should consider a UX to communicate node attributes to the user. I can think of two ways:
I agree with @GuillaumeDesforges's suggestion.
After examining the JSON file we received, I confirmed that the parsedName
field is emacs-numpydoc
instead of numpydoc
for the first package. Therefore, it seems reasonable to use parsedName
instead.
We can easily make this change by replacing the name field in Nixpkgs_metadata
with parsedName
while keeping the pname
outside of Nixpkgs_metadata
. This approach ensures that the data model accurately captures the intended name.
Thanks for the input @GuillaumeDesforges and @zz1874. That also makes sense to me as long as there aren't any key use cases for pname
we are going to miss out on by removing it from the schema.
@dorranh I don't think we need to remove it from the schema if the graph database can handle node attributes.
Isn't pname
a node attribute already anyway? I hope it's not the node id 😄
@GuillaumeDesforges, that is also possible. I might have misunderstood the suggestion above. Was you idea to add an additional attribute (e.g. name
or parsedName
)?
By the way, not to worry - the node id is the output path: https://github.com/tweag/nixpkgs-graph-explorer/blob/05f831f12c171c42de818a6479a35acfc239a6d5/api/explorer/api/graph.py#L96-L98
While browsing the graph we generate for
nixpkgs
today, I noticed some confusing behavior where a package,numpydoc
, had a direct dependency on emacs. I noticed this for some other packages such aspython
as well, and after further investigation it looks like this is a case where multiple packages in nixpkgs define the samepname
. For example, here are a fewnumpydocs
packages extracted from nixpkgs:Since we currently only ingest the
outputPath
andpname
into Gremlin, this leads to confusing behavior such as the case described above.Is this intended in the design, or should we perhaps rely more heavily on the
name
attribute instead to avoid such conflicts?