mkDerivation: Expose pname & version in meta

[jtojnar]

Nix only knows of name attribute and considers pname what parseDrvName spits out. Unfortunately, that fails to account for many real-life packages that have variants or dashes followed by number in their name. Since many of packages in nixpkgs already have pname corresponding to project name, we will export it here. We will fallback to the parseDrvName algorithm when pname is not present.
We handle the version similarly.

This will be useful for Repology as well as any other scripted processing of Nixpkgs JSON dump.

See: https://github.com/NixOS/nixos-homepage/issues/306

[jtojnar]

Well, we need to get the project name somehow, even when pname attribute is not set. We could promote it to meta only when it is in attrs as you suggest but then scripts would still need fall back to parseDrvName themselves (or use the pname attribute introduced in NixOS/nix@cd933b2). This will at least provide an uniform interface.

On the other hand, going your proposed route route would allow us to consider meta.pname vetted, which might be beneficial. Repology could decide to consider packages without meta.pname untrusted or drop them altogether. cc @AMDmi3

[jtojnar]

If pname is not set then it is not a project (in repology's sense and also with the meaning that name does not contain project name and/or version)

As fair as I know, we do not have formally defined semantics for pname.

Would it be correct to extract pname and version from names like "CVE-2017-6827+CVE-2017-6828+CVE-2017-6832+CVE-2017-6835+CVE-2017-6837.patch", "unit-user-.service", "ntfs-3g_ntfsprogs-2017.3.23.tgz" or "daemon.conf" ?

Those derivations would not be listed by nix-env. Which makes me wonder how does nix-env which attributes are packages and which are not.

[jtojnar]

Those derivations would not be listed by nix-env. Which makes me wonder how does nix-env which attributes are packages and which are not.

It looks like recurseForDerivations is used by nix-env to traverse nested atribute sets:

https://github.com/NixOS/nixpkgs/blob/83aa6f5d7f540a088e79941e103bd85a2f0114afP/pkgs/top-level/all-packages.nix#L67

And things like auto-patchelf-hook are not filtered out. Weirdly, Repology ignores it, even though I did not see any relevant ignore rule.

[vcunat]

nix-env anyway will stay with Nix heuristic split (so it will split "package-unstable-20190101" as "package-unstable" and "20190101" irregardless of whether pname is "package", "package-unstable" or absent).

That's one of the reasons I really dislike this "unstable-" versions naming. It confuses things, and I can see almost no advantages of that scheme. For example, I use nix-env -i /some/nix/store/path and there it's not even possible to detect where version starts.

[7c6f434c]

And things like `auto-patchelf-hook` are not filtered out. Weirdly, Repology [ignores it](https://repology.org/projects/?search=auto-patchelf-hook), even though I did not see any relevant ignore rule.

Given the attention to version availability, a completely unique name without version might be enough to ignore by default.

[ryantm]

I agree with @volth that we should not have these fallbacks to parseDrvName because it is surprising to me that it would work like that. pname typically goes into name, so it is weird for name to go into pname in some cases.

Without these fallbacks the change seems quite uncontroversial. You are just saying make the attrs available in meta if they were passed in to mkDerivation.

[ryantm]

If we want to make something like nameForRepology in the website export code with this logic, we could do that.

[edolstra]

I don't think this is a good idea because it creates the possibility of the attributes in the derivation being inconsistent with the ones in meta. (In other words, it denormalizes the derivation, providing possibly conflicting sources of truth.)

[jtojnar]

Yeah, this is definitely a concern but we do need some way to find the version. Since is not extractable from name in general case (for projects containing a -[0-9] or versions starting with [^0-9]), we either need to pass it through some channel that nix-env recognizes (like done using meta here), or teach Nix about version and pname.

[ryantm]

Can we add pname and version to derivationArg instead? Is there still a concern they can be desynced by overrides?

[danbst]

related #75813

[FRidh]

I think that, when pname is explicitly passed, we should check that parseDrvName pname return an empty version.

[stale]

I marked this as stale due to inactivity. → More info

[davidak]

What is the status? What need to happen that this can get merged?

[stale]

I marked this as stale due to inactivity. → More info