Mh, I do think that having the number of dimensions in the derivation name is valuable. Can we maybe set pname to palp but still define a custom name with the dimensions included?

Long term it might be nice to add a meta entry for the repology name, since I think the usecase of encoding configuration information into the name is not uncommon and shouldn't be discouraged.

Mh, I do think that having the number of dimensions in the derivation name is valuable. Can we maybe set pname to palp but still define a custom name with the dimensions included?

I don't think so, because mkDerivation first checks for name, and uses it if available. However, I'm not super familiar with what affects the packages.json that gets consumed by repology. @ryantm

unfortunately, it is not possible:

master:

  "palp": {
    "name": "palp-6d-2.1",
    "pname": "palp",
    "version": "6d-2.1",

using pname + version + name:

  "palp": {
    "name": "palp-6d-2.1",
    "pname": "palp",
    "version": "6d-2.1",

using pname+version only (this PR):

  "palp": {
    "name": "palp-2.1",
    "pname": "palp",
    "version": "2.1",

if you want to reproduce, I found the command to create the packages.json:

nix-env -f . -I nixpkgs=$PWD -qa --json > packages.json

We should fix that. nix-env should be agnostic to how the derivation name is structured. Instead we should write a nix expression that uses lib.getName and lib.getVersion, which use pname and version if available.

I don't plan to work on that myself though, and for now having nixpkgs-update working is more important than a nice derivation name. Thanks for looking into this!