Nixpkgs: repology having problems with extracting package names

[volth]

Issue description

https://github.com/repology/repology/issues/854
repology is unable to reliably split our package names to pname and version

Many packages have no explicit pname and version, only name which is tricky to split

Nix's own builtins.parseDrvName uses a simple heuristic which is unreliable

[AndersonTorres]

How many packages need manual intervention (in the sense that "automatic tools get a wrong result")?

[vcunat]

builtins.parseDrvName isn't really a heuristic per se. It's the only way that nix-env uses AFAIK, i.e. it's how nix defines version comparison.

[volth]

How many packages need manual intervention (in the sense that "automatic tools get a wrong result")?

As a human I am not sure how to split for example "wmii-hg-2012-12-09".
Even after looking at the introductory commit titled wmii-hg: init at 2012-12-09 but
https://github.com/NixOS/nixpkgs/blob/c0b710fc68352d672ff1c450010b35d9992154af/pkgs/applications/window-managers/wmii-hg/default.nix#L6

The automated function which would mark the packages with need manual intervention would not be easier than the automated function which do the split.

[vcunat]

In such cases, I'd probably "rename" them. (Regardless of improving the tooling in some ways.)

[volth]

Also the recommended format for unreleased versions version = "unstable-YYYY-MM-DD" is not compatible with builtins.parseDrvName's logic, it will include "unstable" to the pname

[vcunat]

The manual says

Also append "unstable" to the name

i.e. it is consistent with the splitting rule. The rule is actually older than pname attributes in stdenv's mkDerivation. _I'm not really convinced this part is usually a good practice, though._

[volth]

Perhaps we should start an RFC to (re)define name, drvname, pname, version, status of words like "unstable" and "hg" (package name suffix or version prefix) ...

1. in a consistent way
2. compatible with 3rd party tools (such as repology).

[AndersonTorres]

The issue of "using HG/GIT/CVS/wth" in the name was always polemical. About that, I think the "unstable" should be part of version attribute.

[matthewbauer]

I think putting unstable in pname is so that nix-env -u doesn’t automatically upgrade to the newer version. This is confusing though either way. IMO we shouldn’t carry unstable or unreleased versions of the same package at all, instead allow overrides and overlays to provide a more unstable package set.

[volth]

I think putting unstable in pname is so that nix-env -u doesn’t automatically upgrade to the newer version.

If adding -unstable suffix to the pname is the only way to prevent automatic upgrade, then there is something fundamentally wrong with nix-env

For example, perldevel (technically being unstable) has exactly the same pname "perl" as perl528, will nix-env perform the automatic upgrade?
Or will it automatically upgrade postgresql 9 to 10 ?

[vcunat]

You can mark such packages lowPrio.

[volth]

BTW, this is the function to split name to pname and version which works only for perl-packages.nix
https://github.com/volth/cpan2nix/blob/68b4e6c000c5321415255e70f57ca9fe9641975e/Cpan2Nix.scala#L310-L338
eight regexps + list of exceptions

[AndersonTorres]

IMO we shouldn’t carry unstable or unreleased versions of the same package at all, instead allow overrides and overlays to provide a more unstable package set.

Problem is, sometimes the upstream code doesn't release very often. An "unstable" version includes some valuable modifications, as the TCL_CONFIG environment on OpenMSX

[ryantm]

Repology started to publish its logs at

https://repology.org/repositories/updates

The latest log for nixpkgs-unstable is:

https://repology.org/log/1282366

There are a bunch of errors because they cannot get the version of a derivation or cannot extract the version because of multiple hyphens.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.