Add `trackname` to the list of exposed fields in the API

[rhendric]

The Nix repos store the string used to actually access a package as NameType.NIX_ATTRIBUTE_PATH, which maps to trackname. But the trackname field isn't exposed in api_v1_package_to_json here, which means that Nix tools that consume data from Repology have a harder time finding the specific package being described. Exposing the trackname field by adding it to that function would allow said tools to be updated to make fewer mistakes.

[AMDmi3]

trackname is supposed to remain internal, so it's not the way to fix the original problem. The right way to do it would be to fill srcname and binname(s) for nix properly, and it's in fact one of the few repos for which this haven't been sorted out yet (see repology/repology-updater#944). So would attribute path do as source package name (e.g. something which identifies a package recipe), and pname as binary package name (e.g. something which is used to install or refer to installed package), correspondingly? As far as I remember, I've had a fear that I'll have to introduce a dedicated field for an attribute path, or allow multiple srcnames (likely with position used as a primary srcname).

[rhendric]

So would attribute path do as source package name (e.g. something which identifies a package recipe), and pname as binary package name (e.g. something which is used to install or refer to installed package), correspondingly?

Might work as a hack, but I don't think that's a correct description of the names. Nix(OS) is approximately a source-based distribution, like Gentoo—you wouldn't use one name to build from source and the other to fetch a precompiled binary. (With a few exceptions: firefox is a package that compiles Firefox from source, and firefox-bin is a package that downloads Mozilla's build and adulterates it until it works on Nix. This pattern is uncommon.)

The attribute path is what a user tells Nix to install. It identifies both a package recipe and (indirectly) a particular path in the Nix store which will contain that package's contents when installed.

The pname is a description of an installed package. Not everything in the Nix store is associated with an attribute path, because ‘attribute paths’ are really just a subset of all the possible Nix expressions that can result in a package. If you've applied some custom compilation flags or patches to a package, for example, you've installed a derivation that (probably) isn't associated with any attribute path in Nixpkgs. But that thing you installed still has a pname, which can be displayed by tools to describe it. It wouldn't be very robust to try to use a pname to refer to a particular installed package, though, as many locations with the same pname will tend to accumulate in a Nix store (one of the selling points of Nix being the ability to have multiple versions of the same package installed at once without interfering with each other).

In short, to a first approximation, attribute paths are for user-to-Nix communication, and pnames are for Nix-to-user communication.

Package naming guidelines in Nix require the pname to match, as closely as possible, the upstream package name. So the pname for GNOME Control Center is gnome-control-center. This makes the pname the natural field to use to correlate Nix packages with other repositories' packages. But to install that package on Nix, a user needs to use its attribute path, namely gnome.gnome-control-center. (The pname is not required to be equal to the final component of the attribute path, though it often will be.)

I don't know how best to fit all that into your naming taxonomy. pname already maps to visiblename, so perhaps we should just change the name=NameType.NIX_PNAME mapping to srcname=NameType.NIX_ATTRIBUTE_PATH and that'd be enough? I don't know what the consequences of that would be on whatever Repology does to associate packages across repos.

[AMDmi3]

Thanks for clarification! Well it really does not fit into src/binname scheme well, but mapping NIX_ATTRIBUTE_PATH to srcname whould be fine for the time being as you've done in #1317. This problem described in this issue should be solved after everything is deployed and repositories are updated - it will be possible to get a link to API (and other pages) based on an attribute name, see https://repology.org/tools/project-by

[rhendric]

Thank you, this should be very helpful!